[TYPO3-ect] "extension package"

[Daniel Brüßler]

Thanks Elmar, Steffen, Daniel, Franz, Christian,
here's the second version of it. ;-)

"extension package" v0.2
(compare with: ".jar" Java Application Repository, ".deb"
Debian-package, ".tar.gz" PEAR-package)

== Examples of other frameworks ==
A .jar can be a collection Java Class Files. For example xalan.jar to
parse xml and transform xslt. Cocoon is a collection of several .jar
files, one of them is xalan.jar

Here it is always clear what "xalan.jar" means, because the project
tells all developers what is inside and what will be inside in future.

A .deb has some C or C++ files. For example libxml2. PHP5 is a mix: It
has many files, and contains some libraries like libxml2. KDE is a
bigger mix: It contains many dependencies to libraries and to some
applications what also depend on some libraries. GNOME is another one:
Another GUI und applications but many libraries are the same.

A .tar gz PEAR package has one or many php-classes and can have many
dependencies to other packages.

## In all these cases it's always clear what *is inside* and what *will
be inside*. When a packager would make a chaotic package no one would
use it.

== Examples TYPO3 ==
The "ect" package, what has the task to provide an easy installation for
extension-developers in ECT.

Now we could provide a "libeasy" package, that only has the parts
everybody needs and what doesn't have problems with something else. A
package that makes it *as simple as possible* to jump from pibase to
lib/div.

We could provide a "partner" package, what just has the needed
sub-extensions - without authentication, because some want to
authenticate against username/password, some against LDAP.

We could use it for the dam, for example two parts: the main logic as
"base layer" and the interfaces to other parts of TYPO3 as "interface
layer". So dam-based galleries can depend on "dam", but several people
can focus on that single part, what they really want to do.

== How ==
One package contains
* emconf-file with list of all dependencies
* a "manifest"-textfile what tells what the extension *does* support and
*what not*
* a list of the parts inside what maybe can be forked to a sub-project
* maybe a setup TypoScript, maybe some php-files

== Advantage ==
It's much easier to split a mega project, to the main-project and some
sub-projects. That's the architecture of TYPO3 :-) We have the core and
extensions. Why not have a "main" extension and it's addons and provide
it as "extension package".

== Disadvantage ==
A packager must write a list what dependencies are fixed and what will
be fix, and what will come in some months.

== Carefully ==
An extension package must be managed very carefully and the package
should/ has to stay in contact with the developers who use it. Here in
the ect-newsgroup that's very easy.


kind regards
Daniel Brüßler