[Typo3-dev] System Extensions, part II
Kasper Skårhøj
kasper2004 at typo3.com
Tue Nov 16 15:42:09 CET 2004
Sorry, the URL to the current selection of global extensions is:
http://130.228.0.33/t3dl/src/global_extensions_for_3.8.0.tgz
On Tue, 2004-11-16 at 15:41, Kasper Skårhøj wrote:
> Hi Folks,
>
>
> Maybe you remember I send a mail in May about how many of the current
> global extension will move to the sysext/ (System Extensions) folder. I
> also attached a document which outlined the principles behind including
> a list of actions I wanted to take and an invitation to comments. AFAIR
> only a few responded so I now just did what pleased me best.
>
> So here is the overview. From the next version of TYPO3 you will find
> these extensions in the sysext/ folder:
>
> aboutmodules
> belog
> beuser
> cms
> context_help
> css_styled_content
> extra_page_cm_options
> func_wizards
> impexp
> indexed_search
> info_pagetsconfig
> install
> lang
> lowlevel
> setup
> sv
> sys_action
> sys_note
> taskcenter
> tsconfig_help
> version
> viewpage
> wizard_crpages
> wizard_sortpages
>
>
>
> The ext/ folder (global extensions) will be empty from now on and you
> can put your own extensions in there which you will have to manually
> update from TER when needed. Probably we will distribute the global
> extensions one last time with the next version as a service to you so
> you will have an easy upgrade of TYPO3. The remaining global extensions
> are:
>
> cms_plaintext_import
> conf_userts
> direct_mail
> direct_mail_subscription
> extrep_wizard
> feuser_admin
> freesite
> imagelist
> kickstarter
> metatags
> phpmyadmin
> plugin_mgm
> quickhelp
> rte
> rte_conf
> setoldpluginlist
> skin1
> static_file_edit
> sys_messages
> sys_notepad
> sys_stat
> sys_todos
> sys_workflows
> taskcenter_modules
> taskcenter_recent
> taskcenter_rootlist
> tipafriend
> ts_language_de
> ts_language_dk
> ts_language_fr
> ts_language_nl
> ts_language_no
> tstemplate
> tstemplate_analyzer
> tstemplate_ceditor
> tstemplate_info
> tstemplate_objbrowser
> tstemplate_styler
> tt_address
> tt_board
> tt_calender
> tt_guest
> tt_news
> tt_poll
> tt_products
> tt_rating
>
> For people updating the core from CVS later today you should grab this
> TAR ball:
>
>
>
> BACKGROUND.
> This is a copy/paste from the document I send to the list in May if any
> of you want to study the background for this change and the principles I
> believe should guide our selection of system extensions:
>
> <snip>
>
>
> In the debate about TYPO3 version numbering, separation of core and
> extensions and marketing of TYPO3 as a whole, we finally worded what we
> are already doing by favouring certain extensions in the distribution
> (like the global extensions): "System extensions"
>
> "System extensions" is a word for the extensions that are considered
> cornerstones in TYPO3 and the features of which are officially promoted
> as something the system includes. This proposal is a suggestion for how
> we can technically underline this approach in the future.
>
> We will:
>
> * Remove *all* global extensions in the distribution (some of
> which will become "System extensions", see below)
>
> * Select all extensions that are now considered "System
> extensions" and include in the core folder "typo3/sysext/".
>
>
>
>
> Pros:
>
> * Quality assurance: System extensions will represent "cream of
> the crop" of extensions, both in quality and general usefulness.
>
> * Wholeness: TYPO3 comprised of a) core and b) system extensions
> can better be understood as a whole. The feature list will
> reflect the combined features of core and system extensions.
> This is also what is marketed/communicated outwards. They also
> share branching/tagging for releases in CVS which in again
> reinforces the concept of a whole.
>
> * Larger "Core" team: The "Core developers" list will naturally
> include all authors of system extensions. These people will have
> access to core CVS (although initially restricted to their
> extension workspace). This might also make it more natural to
> recruit people into working on other parts of the core! Finally,
> the "one-man-show-fear" people have will hopefully be
> diminished, not because I loosen grip but because it becomes
> evident that system extensions is a part of the core and slowly
> is becoming the larger part of the system. Yet, we don't loose
> the advantages of having clearly identified working areas (each
> system extension) for the various core developers.
>
> * Easier CVS usage: We avoid the illogical situation that current
> global extensions that many consider part of "the core" are not
> in the Core CVS repository. They *will* be in Core CVS as
> "system" extensions (like "cms" and "lang"). We don't solve the
> symlink redundancy problem though.
>
> * Easier updates for the "whole system": Before, people had to
> keep track of updating both core AND sometimes system
> extensions. Now, they don't have to think about that anymore,
> just update the core and all system extensions will
> automatically follow.
>
> * Global extension space free for use: With an empty global
> extension space people can fully utilize this for their own
> installed extensions. Before this was a big problem because in
> reality the global extensions was distributed with the core just
> as much as the system extensions was. So in this new situation
> peopel can freely choose "global" or "local" install based on
> their preference without any (or much fewer) drawbacks related
> to upgrades.
>
>
>
>
> Cons:
>
> * The size of the core will grow with the size of the new system
> extensions (but of course fall with the size of abandoned global
> extensions). Maybe that is not a problem.
>
> * The PHP developers experienced that having many extensions
> distributed with the core made it hard to manage that all
> contributers finished on time. So: We might face problems
> getting new releases out when someone did not deliver what they
> promised. But we can also introduce principles to solve this.
> One could be two-person maintainer ship. Another is the
> principle that if someone did not finish his work in time, we
> just take the old version from previous release.
>
>
>
>
> Transitional phase:
>
> The transistion will be easy. First release of this structure will
> simply ship all global extensions that were not promoted to system
> extensions (thus all extensions that came along in previous release are
> still there, just some switched position). However this will be the last
> time that happens - from that point the global extensions is a local
> matter how people organize them and the system in general will not
> impose any requirements on them.
>
>
> Qualifying as System Extensions
> This is the topic where we need some debate on the dev-list.
>
>
>
> I think we should select the new collection of system extensions based
> on two major criterias:
>
> * Feature coverage: That is when an extension (uniquely?) offers
> an announced feature of TYPO3. Examples are DAM, DBAL, RTE,
> RealUrl etc. Some types like "Guestbook" does not apply since
> many of them might exist and are low-complex.
>
> (A nice sideeffect of looking at it this way is that it will be
> clear what areas of features are not yet covered by TYPO3!)
>
> * Popularity: That is extensions which are so widely used by the
> community that it makes good sense to include it for convenience
> reasons. We might also assume that this is a sign of good
> quality. Examples are: Auto Make Template, Template Selector,
> Gallery etc. (see popular list on TYPO3.org)
>
>
>
>
> Another set of criterias could be (and supplements the above):
>
> * Either so simple that no one would make an alternative
>
> * Or so complex that a single one should do it all
>
> * Never extensions where many flavors would select different
> approaches anyways!
>
>
>
>
> Finally there are overall requirements to extensions:
>
> * Size: The extension must not be bloated in size (phpMyAdmin
> fails this test for example, being 2 MB or more).
>
> * Author: The author must be committed to maintenance and
> participate regularly as a core developer.
>
> * Documentation: Adequate documentation accomplished
>
> * CGL: Adheres to TYPO3 coding guidelines
>
> * Review: Can qualify for a "cigar" rating in a review.
>
> * Dual-maintainer: [Idea] At least two people are involved in the
> development, each having access to the CVS of the extension and
> authority to carry out changes (to avoid dependencies on a
> single author).
>
> * Goals: The extension must have a Todo list and the author/team
> behind must announce goals (if any) to achieve for each planned
> release of the core.
>
>
>
> Selecing the new System Extensions
> Next step is practical: To select which extensions will be promoted as
> system extensions. This will include a look at a) the current global
> extensions and b) the TER.
>
>
>
> Global extensions:
>
> In this table you will find all current global extensions listed. This
> is an explanation of the columns:
>
> * Extension Key / Title: Obvious
>
> * New status: Indicates the suggested new state (this is up for
> debate!):
>
> * "enable" / "include" : Means the extension is promoted
> to become a system extension and if set to "enable" it
> will be installed by default.
>
> * "-" : Means the extension will NOT be a system extension
> and has to be installed separately.
>
>
> * Pkg (package): [new concept] For extensions that are not system
> extensions anymore we thought it might make sense to define
> packages of extensions for various purposes. For instance there
> will be a collection of extensions which are typically useful
> for developers - they will be in a package and they can be
> installed / upgraded in one click. Technically this means we
> need to extend support in the extension manager so more
> extensions can be installed/upgraded in one go.
>
> * Cur (Current status): "S" means "Shy" extension - basically it
> indicates that this extension is currently one of those loaded
> by default in blank installations. "I" means "Internal" which
> means the extension is somehow favored by the system in a
> hardcoded way.
>
> * Needs: Sums up if there are any development plans for this
> extension or some other needs for it.
>
> * Maintainers: This tells who will be maintaining the system
> extension. In most cases there is a "?" sign and that means we
> need someone (2 people at least) to take over maintenance!
> Please volunteer!
>
>
>
> </snap>
>
>
> Finally, I have listed some suggestions to candidates that might go into
> the sysext/ folder as well, all extensions which are currently not
> global.
>
> Please comment on this and suggest others if you think they fit the
> criterias given above.
>
>
>
>
>
> Extension Key
>
> Reason
>
> templavoila
>
> Popular
>
> Unique feature
>
> automaketemplate
>
> Popular
>
> dbal
>
> Cornerstone feature
>
> dam
>
> Unique feature
>
> rlmp_officedisplay
>
> Unique feature, but specific
>
> realurl
>
> Unique feature
>
> rtehtmlarea
>
> Unique feature, democracy (Offers
> RTE available for both Linux and
> Windows)
>
> NOTE: May be one of the other
> HTMLArea based RTEs instead! We will
> select the best.
>
> newloginbox
>
> Popular
>
> awstat
>
> Popular
>
> rlmp_tmplselector
>
> Popular
>
> de_phpot
>
> Popular
>
>
>
>
>
>
--
- kasper
--------
Please notice NEW EMAIL ADDRESS for 2004!! (due to SPAM-contamination)
"kasper2004 at typo3.com"
More information about the TYPO3-dev
mailing list