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.
Geoff:
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 perspective.
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 http://dpml.net/james/james.server.bar. 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 http://dpml.net/james/james.server.bar
WARNING - DO NOT TRY THE FOLLOWING IF YOUR MACHINE IS ALREADY SETUP AS A MAIL SERVER
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 http://dpml.net/james/block.xml -config http://dpml.net/james/block.xml 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 http://dpml.net/james/james-server.bar?profile=default&domain=osm.net
The contents of the jams-server.bar 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 mailto:[EMAIL PROTECTED]
