cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [design] Cocoon Blocks 1.1
Date Sat, 09 Nov 2002 01:45:41 GMT
Miles Elam wrote:
> 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.
> 

Ok, I'm back. I had some 7 pints of beer and with a day-empty stomach 
before we hit wagamama (http://www.wagamama.com) so not all my synapses 
could be fully functional... but anyway... here I am.

>> By now just a hint: when we'll have cocoon.apache.org, 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.  

All right. I was hoping to discuss this later down the road, but I think 
it's good to give perspectives right up front. Yes, I'm aware of this 
issue and I do have solutions to propose for that.

> 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.

Hey, I'm not RMS :) I know that.

> Lets say a vendor (correctly) recognizes Cocoon as a truly innovative 
> product and sees a niche for itself for creating custom components for 
> it.

This is already happening. A lot.

> 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.

That's obvious.

> If and when Cocoon really takes off

If? :) [just kidding]

> 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.

Careful, you are mixing concerns.

One concern is about mirroring and load distribution. That will be dealt 
with the mirroring effort that is going on in infrastructure@, our block 
library will simply point you to the right URI (we could do things like 
geo-spotting or explicitly having the client indicate the location, 
anyway that's a implementation detail)

Another concern is multiple block libraries.

And yes, that is already (even if partially) touched in the design paper 
I sent.

> 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.

Yes, I see this.

But again, be careful not to mix concerns.

One usage scenario is about automatic discovery of blocks, another is 
direct installation of a deployment descriptor.

Think of something like this [it's an example, not a proposal!]

  <deploy>
   <block href="http://myblocks.org/whatever.cob/>
   <block href="http://cocoon.apache.org/dist/blocks/fop-1.2.3.cob/>
  </deploy>

and your customer is happy. Note that the URI-based discovery phase it's 
not needed anymore in this case.

[NOTE: the URI is transparently redirected to the mirror one depending 
on language headers, geo-spotting,  round-robin or other means]

> 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.

Yes.

> 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.

Yes, I see your point very clearly, but my point is: let's follow darwin.

I'm *very* afraid of building something without having a touch of 
reality. I want to start with one library of blocks and if this doesn't 
scale with the amount of blocks we end up having (that is a dream, 
actually, we are not a 8Gb linux distribution!) we'll think about how to 
fix that.

> 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.

Let's do it the other way around: let's start from cocoon.apache.org and 
if we can't scale, we'll think about how to fix that, ok?

I perfectly see your point, but I think we should avoid designing and 
implementing stuff just because there are parallels in other areas. 
Design by parallelism is a very subdle anti-pattern.

And for your commercially-friendly concern, I don't think that any 
company will ever do block deployment out of dynamic discovery anyway. 
And if they want to do it, I'd suggest we talk about that when the issue 
emerges.

What do you think?

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message