[Typo3-typo3org] TER 2.0 - updated concept!

[Robert Lemke]

Hi Sven,

Sven Wilhelm wrote:

> Install script:
> Would be better to really split the that into four files. It makes sense
> by the dpkg format and also here. Also it makes sense to call the
> scripts with different package states, eg. Debian knows several package
> states: install, removed, purged. On installation it will be checked if
> it is an installation or an upgrade, so an install script could be
> called with these two states. The remove or purge was also written as
> idea a few postings before.

I am still in favour of having _one_ file with four (or more) methods. Most
times it might be only a few lines of code you want to execute while
installing or removing an extension so let's keep the filestructure as
cleen as possible.

The package state and the requested action should definately be one of the
parameters passed to these methods.

> Format of t3x:
> Couldn't that be just a normal zip file?
> Pros: It's a standard format that could also be used in other
> environments such as an IDE or by other external tools. Due the fact
> that the TER uses soap as its protocol several restrictions on how to
> communicate are done, so opening the way for other tools could be a
> chance.

A format similar to SXW files would be nice (zipped with XML meta files
etc.) but that would be a completely new thing. I think we should leed the
discussion about a new T3X format independently from developing the TER
because ther TER has to support the old format anyway.

> Virtual extensions:
> Could be that I didn't understand this full. A library package that's
> packaged as an extension and is needed should be a real dependency.
> If your thoughts were something like a dependency on eg. "PCRE enabled
> your PHP environment" than that could be just normal dependencies.
> To include that in the dependency list is a great thing.

I think you understood me right. The ADODB extension for example is a real
extension because it contains the ADODB library. ImageMagick could be a
virtual extension because IM itself is not included but you can define a
dependency on it.

We could even think of Meta-Extensions like "graphics handler". The
dependency would be fulfilled if either ImageMagick or GraphicsMagick is
installed because the both are graphics handler or whatever you might call
them.

> Extension.xml:
> I would take the Debian way there. Download the repository on request,
> not by default (the part apt-get update). Be able to merge several
> repository lists to a final internal. While this generates some "costs"
> for processing, only do it on a request-by-user base.

Yes, I thought about that. What I didn't like was that you won't realize
that a new version of an extension exists unless you apt-get update. So in
the end most people will fetch an updated extensions.xml each time they
want to download extensions.

How about caching the merged extensions.xml for the lifetime of the current
backend session?

> As I posted in the past, first ideas for such a xml file. Did not get
> any feedback.
> http://icecrash.com/fileadmin/data/typo3org/Extension.xml

That is something to start with but of course it's not complete yet. If you
like you could try to create a complete extensions.xml and then ask for
feedback so we can discuss what you did?

> I take over the DTD-writing part if wanted.

DTD, XML Schema or RELAX-NG?

> Also providing a base url for typo3 standards would be nice.

yes.

> I will publish the first draft of the next EM during 07. May (you did a
> great bundle of my documentation work :)

Great, just create another document we can put into our TYPO3.org documents
section and then discuss it.

Cheers,

-- 
robert