cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Miles Elam <>
Subject Re: [design] Cocoon Blocks 1.1
Date Fri, 08 Nov 2002 19:03:52 GMT
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, we'll have our 
> own 'uber library' of blocks for block discovery.
> 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?

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.

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 (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: (or whatever the path turns out to 
be) and would be no different than what you proposed.


- Miles

To unsubscribe, e-mail:
For additional commands, email:

View raw message