[Typo3-typo3org] TER 2.0 - updated concept!

[Robert Lemke]

Christian Jul Jensen wrote:

> What an amazing piece of work! Sets new standards for development
> processes within the project. Respect!

thanks ;-)

> p2_1: "repositories.typo3.org", somehow seems like a weird name for the
> master extension repository, I don't have a better suggestion though.

I don't have a better one either - anyone?

> p3^1: "Super mirrors", will there be any pushing of data from the master
> rep, or is it only based on cronjobs on the super-mirrors? 

I think we should let the super mirrors poll from the master rep, that
should be stable enough.

> "supporting mirrors synchronize with the master repository"(p3^8),
> wouldn't it suffice to sync with the super-mirrors? To do some load
> distribution, and also if nobody fetches the extensions from the
> super-mirrors they only need to contain the hashes. I suggest syncing
> supermirrors to the master by pushing from the master, and having
> supporting mirrors sync with the super mirrors. This will protect the
> master server from load and scalability is simply a question of adding
> super-mirrors. Did I miss somethin important?

We could do that, however I didn't plan to have too many supporting mirrors
anyways. Let's say we have 10 supporting mirrors and 3 super mirrors to
start with - that should be fairly enought to transfer some tiny files.

We just have to find out how much load an RSYNC causes.

> p4^2: What's the "/t/e/" in the path?

the first two letters of the extension key. Imagine we have 5000 extensions
- that can slow down file access on certain file systems, so this is a
measure to keep the amount of files per directory low.

> p4_4-1: why? technically it should be fairly simple to supply the same
> extensiosn that power TYPO3.org (but of course that would have very low
> priority to support this), or is it to ensure that people don't provide
> "special" mirrors to easy?

Got me ... Yes, that is to give us a small head start so we strengthen
TYPO3.org as a central place for TYPO3 resources. But it won't be a problem
to publish a "TER light" FE-Plugin ... 

Or do you think that's unfair?

> p5: "Specifications", I suggest adding doc as a special dependency between
> an extension and it's documentation. If I look at how I use apt, I can
> imagine that I will always want to download docs automatically, but not
> other recommended extensions. Also it will be easier to determine whether
> an extension provides docs or not, one wekaness of splitting it up is that
> we risk undermining the perception that an extension is not fully done
> without docs.

I think Debian distinguishes between "recommends" and "suggests", would that
be enough difference?

> p5: "Virtual extensions", brilliant idea, I love it!

Rafael Schär triggered my brain with his PEAR integration thread at the dev
list ... But I think the concept of virtual extensions is not new outside
TYPO3.

> p6: "Install scripts", I also really like this. My first thought though
> was 'oh no don't use fixed names', it would be 'cleaner' to let the
> extensions register methods, but maybe this is just one of the cases where
> it doesn't make sense to take OO to the maximum extend. It probably only
> gives an overhead of function calls without adding any flexibility.

I think we should stick to static names and let you instantiate an object,
call a method or whatever in that little function - flexible enough.

> One issue I missed:
> 
> Will it no longer be possibel to browse TYPO3 .org, select extensions
> there and download in the EM based on this? I'm not sure how many people
> use that feature, but did you forget about it or simply leave it out?

I think that won't be possible because we don't connect to TYPO3.org when we
download extensions.

-- 
robert