[Typo3-dev] System Extensions, part II

[Kasper Skårhøj]

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"