Miles Elam wrote:
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.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.
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.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.
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.Careful, you are mixing concerns.
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.
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 <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
