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.
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.
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?
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. (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?)
Geoff
