cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <>
Subject Re: Ant/Maven/Centipede discussion
Date Thu, 09 Oct 2003 21:23:07 GMT

Geoff Howard wrote:

> Stephen McConnell wrote:
>> Geoff Howard wrote:
>>> If you havn't read up on the blocks docs on the wiki lately (the 
>>> last two weeks) you really should.  Stefano has put a good series of 
>>> pages up detailing the plan and the current implementation ideas. 
>> Another followup question related to the following note on the wiki:
>>    * dependencies:
>>          o the URI(s) of the blocks on which this blocks depends on
>>            (optional)
>> I'm thinking about this relative to Avalon Merlin Block 
>> dependencies.  Under Merlin a block dependency is implicit - not 
>> explicit.  By implicit I mean that you can establish the dependencies 
>> that a blocks has relative to the computational dependencies that the 
>> blocks implementation exposes.  This means that a deployment system 
>> (tool or container) can resolve dependencies at runtime, using (a) 
>> locally available resources, (b) external repositories, or via more 
>> complex means (roadmap stuff) using (c) a remotely accessible service 
>> provider, or (d) remotely provided serialized block descriptions.
> And as I see it and understand it - it must be this way because a 
> Cocoon block as envisioned so far employs a "weak typing" in some of 
> the "services" (maybe better expressed as "behavior") it exposes.  The 
> reason services is in quotes is that they are not Avalon Services but 
> weakly (intentionally) defined resources.  For example, an xsl (though 
> currently it is required that this be exposed via a pipeline).  
> Clearly in that case all the explicitness of java that makes 
> computational dependencies possible is out the window and you have to 
> fall back on some rude indentifier for a generalized block "behavior".
> By the way, I think you and Stefano were misunderstanding each other 
> over the description of this issue.  When he was describing blocks as 
> "functional" units you seemed to read that more as "function_ing_" 
> (i.e., 'they work' or 'self-contained').  I think he was describing 
> this generalized behavior aspect.
> Now, a major question in the back of my mind is whether this 
> generalized behavior contract can be represented (implicitly from a 
> block developer's standpoint) via an Avalon Service which may make 
> Avalon/Merlin blocks closer to Cocoon blocks than they seem at present.


The above is a good summary.  It also hilights the need to describe weak 
typing - but I'm sure that underling this is a correlation with strong 
typing and general service management concerns.  My hunch is that the 
soft/weak typing is comming from a data-driven perspectives wheras the 
hard/strong typing is comming from the comutational service management 

> Having said that though, I definitely resonate with the need to get 
> going.  I feel the best way forward is to look for true synergy 
> (either present or future) in the implementation phase without bogging 
> down.

Similar sentiments here.

There are two distinctly different ways of looking at synergy - each 
with different risks and potential impact.  From a component/service 
management perspective there is some interesting stuff evolving in 
avalon that has significant potential here.  The two different aspects 
concerns (a) passive usage - as in using containment tools for service 
deployment, and (b) active usage where container side APIs are 
extended.  Generally speaking the active usage is something I'm not keen 
on seeing - i.e. directly using container-side APIs is something we 
should be avoiding.  But there are exceptions - for example the 
meta-info package and repository packages could be highly useful in 
dealing with some of the issues currently in focus. 

>> What I have not resolved in my head yet is how the dependency url for 
>> cocoon blocks translate to computational descriptions (or to put this 
>> into Merlin terms, how can I translate a cocoon block uri into 
>> computation service request that could be used in Merlin to return a 
>> serialized Merlin block descriptor)?
> I am not sure I have wrapped my head around the parallel universe to 
> even understand the question.  Ever see the Seinfeld where they meet 
> up with the "bizarro" parallel Seinfeld/Kramer/George? 

And a similar feeling from the other side of the spectum :-)

A key thing in the above question is the point that things like XML 
descriptors rapidly dissapear in the current Avalon object model.  You 
have XML descriptors of component types (detailing things like 
dependencies, context criteria, etc.) - the meta info.  These get 
translated into Type instances.  Then above this you have a similar 
process with the block.xml files with builders that translate XML into 
deployment and container distrectives (meta data).  Above this you have 
a meta model - which brings together meta-info descriptors with 
meta-data  and a runtime context.  The end result is a deployment model 
and this is the thing that is used when updating configuration, or 
adding a ne component or sub-container, etc. 

All of the meta-info and meta data is serializable - which means that 
you could be creating or updating descriptions on one machine and 
sending them to another machine for execution.  So from my point of view 
- when I receive a url referencing an Avalon Block, I'm thinking to 
myself that what I have received is a complete object model of a 
deployment scenario.  When I review the Cocoon docs - I'm seeing the 
notion of urls as references to blocks - and I'm wodering if there is a 
parrallel here.  Certainly when I look at the docs and read what sort of 
info is being expressed - there *are* significant parrallels.

> I have read through the Merlin docs you pointed to and plan to start 
> playing with it some.  I've also started looking into James in part so 
> I can understand its move from Phoenix to Merlin.  

You should take a look at the contents and manifest from of  The bar file contains a package 
of james specific resources that can be installed into the local merlin 
repository usig the following command:

$ merlin -install


If you machine is not declared as a mail server - you could try a rapid 
James deployment.  Please note that if your machine is already a mail 
server the following commends should fail due to port conflicts - but if 
you current server is down - the following will lauch and start 
processing incomming messages and will trash messages as spam because 
you have not configured any users. 

$ merlin -config config.xml

Currently the bar file uses the manifest to hold information of the 
group it is defining.  This will be expanded to include a lot more 
content dealing with declaration of default configurations, installers 
and so on.  I.e. lots of work in progress but at the end of the day we 
will have secure executable blocks that will allow the simplification of 
the above to something like:

$ merlin

The contents of the is interesting in that it provides a 
good overview of how other components make up the block implementation 
and how the block isolates and exposes specific service.

> (By the way, does anyone know why in the world does that not have a 
> more functional listserv?  It doesn't seem that hard to implement with 
> what's already in place.  Have I missed some complexities or has it 
> just never itched anyone enough?) 

Don't know - but I'll ask the question.

Cheers, Steve.

> Geoff


Stephen J. McConnell

View raw message