Stefano Mazzocchi wrote:
I'm in a hurry now (going to the london gettogether right after this, All Bar One on Regents Street, London if anybody else wants to show up) but I will reply in full detail tomorrow.No problem. Have fun! I wish I wasn't eight time zones away from you or I'd join in on the sharing of pints.
By now just a hint: when we'll have cocoon.apache.org, we'll have our own 'uber library' of blocks for block discovery.That works for storage issues and for getting newest versions, but it is a single point of failure and leaves out one major group: commercial vendors. I love free (libre) software, but commercial software exists, some of it is good, and if they have a revenue stream they can be terribly prolific with code production.
The idea is simple:
1) I give you the block behavior
2) you give me a list of blocks that implement this behavior and the location where I can download them
Nice simple, effective and implemented with a simple POST request and XML response.
What do you think?
Lets say a vendor (correctly) recognizes Cocoon as a truly innovative product and sees a niche for itself for creating custom components for it. If their product costs money (which it almost certainly will in this scenario), they don't want people to be able to automatically download their products without payment. If and when Cocoon really takes off, the sheer number of component producers -- commercial and open source -- would surely either (a) overwhelm the component maintainer on components.cocoon.apache.org (or whatever the hostname) or (b) become so large and unweildy a list with so many competing products so as to be much less usable by the Cocoon user.
On the other hand, if you have an equivalent of Debian's "sources.list" -- a list of all of your possible download points -- you can easily add/remove access points as needed, allow for failover to alternate servers, allow for multiple types of sources (think stable versus beta versus bleeding edge), makes sure that people always have the most recent version in case of slow rsync to mirrors, and finally it would allow a vendor to bundle their services with a Cocoon package.
Cocoon won't go as far without local dealer support. Most of the time, end users won't be downloading Cocoon, Tomcat, et al and setting up their own box. Most of the time, they call local consultants, have them make offers, choose the one they like the best, and have them set it up. If those vendors can just add themselves to a list in their custom Cocoon package, they do not disrupt the community with highly specialized components, and vendors have an "added value" (*ugh* sometimes I really hate marketing-speak) they can tout to their customers. In other words, they'll have a greater incentive to help propogate Cocoon to others.
Open Source projects of course would be listed on the main components list. At such time where enough vendors get visible enough or provide enough utility in their components so as to warrant further exposure, a separate list similar to Debian's (I keep bringing it up don't I...) non-free could be set up; Once again, this does not disrupt anyone else. On the same token, the lists could be split if they grew too large.
You end up with much less control over the pool but the pool is much larger. Sometimes the key to success is making sure you include everyone. Other times, it's just making sure people get out of each others' way.
For the time being, the "sources.list" would only have one URL: http://cocoon.apache.org/components/ (or whatever the path turns out to be) and would be no different than what you proposed.
Thoughts?
- Miles
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
