Sylvain Wallez wrote:
>
> Stefano Mazzocchi wrote:
>
> >Even if the flowscript discussion isn't finished, I think we have
> >reached an important conclusion on that side: a flowscript isn't a
> >sitemap replacer, but a sitemap augmenter.
> >
>
> A minor remark : could we avoid the use of "flowscript" or "flowmap"
> which imply the way they're implemented and speak simply of "flow" which
> only designates the functionality ?
Ok, no prob.
> Why should COBs be downloaded from a remote location ? Do you really
> think people will allow remote code to run on their production servers ?
No, not remote code, but packages downloaded from remote locations (like
anybody has always been doing!).
Think about it: you have apt-get, red-hat rpm updating, ximian
red-carpet, FreeBSD ports, Windows Update, Ecplise update manager, JEdit
plugins... just to name a few.
I don't think nobody will ever mess with a production environment, but
during development, one might want to update the blocks used to the
latest bugfix releases, or even decide to use another implementation
(here is where polymorphism kicks in) of the block used before, because
it has, say, better performance or implements new features.
Blocks will not only make it easier to deploy stuff on a production
environment, but also on development.
> It looks a lot like a Phoenix block .xinfo file. Couldn't the same
> syntax be used ? I'm don't know much about Phoenix services so this may
> be a silly question, but what could be the relationship between a Cocoon
> block and a Phoenix service ?
I still have to investigate this in detail but one thing is for sure: a
cocoon block *might* be an extension of an avalon block (please don't
call them "phoenix blocks" because Phoenix is just the codename of the
*implementation* of the block container).
I'll report on this later.
> Ok, here's the need for remote code. Although a catalog is good to help
> resolving dependencies and discover existing implementations, I'm still
> not sure about auto-deployment of downloaded code on production systems.
Nothing is *automatically* done, nothing happens behind your back. What
I envision is a block management interface on top of Cocoon that *helps*
you during the deployment by suggesting the location of the blocks that
implement the behaviors your own blocks depend upon.
There is no automatic deployment taking place: the deployer chooses what
package to install. The fact that is downloaded from an apache.org
domain or uploaded via web or found on the local file system is just a
detail and if you don't trust those components downloaded from the
outside, simply don't use them, but use your own on your local system.
Up to you, but Cocoon will *never* do something automatically behind
your back.
Also, note: it is possible to follow the Phoenix approach of having
Cocoon generate a 'service package', which is a collection of all the
blocks that make up your service and that you can deploy directly on a
production server without having the need to go around shopping for
blocks.
Anyway, please understand that these are just implementation details and
they do not limit the scope of the block design concept.
> > 5) Cocoon checks that all dependencies are met, then unpacks the blocks
> > 6) Since 'forrest.cob' exposes a sitemap, the deployment manager asks
> >the deploying user where he/she wants to *mount* that block in the
> >managed URI space.
> >
>
> It seems to me block mounting is in fact the configuration of a "root"
> Processor component (the interface implemented by the sitemap) that
> performs first-level dispatching between mounted blocks. This allows to
> keep unchanged the architecture that exists today.
I really don't know: I didn't want any technical details to constraint
the design, so I didn't really look at how to implement it. But I'm
pretty confident that it won't be hard to do given the current and very
flexible architecture.
> Now I don't think all blocks should be mounted on an
> externally-available URI : some blocks will provide only services to
> other blocks and no external service. The sitemap for such blocks is
> likely to contain only internal-only="true" pipelines, but then why
> should we have to mount them on an external URI ?
Good point. In that case, we might add another flag to the block
descriptor to indicate whether or not the sitemap should be mounted on a
URI space available to the outside.
> >For example, the forrest.cob/sitemap.xmap file could contain a global
> >matcher which works like this:
> >
> > <map:match pattern="**/*.html">
> > <map:aggregate element="site">
> > <map:part src="cocoon:/{1}/book-{1}/{2}.xml"/>
> > <map:part src="cocoon:/{1}/tab-{1}/{2}.xml"/>
> > <map:part src="cocoon:/body-{1}/{2}.xml" label="content"/>
> > </map:aggregate>
> > <map:transform src="block:skin:/stylesheets/site2xhtml.xslt"/>
> > <map:serialize/>
> > </map:match>
> >
> >please note the
> >
> > block:skin:/stylesheets/site2xhtml.xslt
> >
>
> IMHO, this example goes strongly against the benefits that blocks want
> to bring. The functionnality brought by the 'skin' block is... skinning.
> It's not an XSL stylesheet at a particular location. What if someone has
> written the killer skin for his site, but this skin requires a
> multi-stage pipeline that cannot be represented by a single stylesheet ?
>
> The contract of a block should be services identified by their URI, and
> not files at well-known locations (even if these 'files' are in fact
> produced by a pipeline).
Great point, Sylvain. I must admit I like your suggestion of forcing
blocks to expose their capabilities via a URI space mapping, decoupling
it from actual implementation makes perfect sense.
I agree, accessing resources directly mixes concerns.
> So what about something like :
> ...
> </map:aggregate>
> <map:call resource="block:skin:/site2xhtml"/>
> </map:match>
Hmmm...
> This call "jumps" to a service provided by the block and its URI is part
> of the block's contract. We don't care (because we don't have to) if the
> service is implemented by an XSL or by the next-generation transformer.
This is absolutely true, I agree, but this requires more thinking on the
sitemap semantics (see below).
> What the "jump" does is feed a pipeline in the block with the result of
> the current pipeline. The whole pipeline is terminated in the called block.
>
> But just as a pipeline can serialize or not depending on if it's an
> internal request or not (see SitemapSource), the same service could be
> used as a transformation. We could then write something like :
> ...
> </map:aggregate>
> <map:transform type="pipeline" src="block:skin:/site2xhtml"/>
> <map:transform type="urlencoder"/>
> <map:serialize/>
> </map:match>
>
> By considering blocks as pipeline services, we really achieve true
> polymorphism for blocks, because we totally abstract the way their
> contracts are implemented.
>
> [note that all the above isn't in fact block-specific and can be made
> today inside a single sitemap]
Exactly, the above is not block-specific. So I'll separate the
discussion an other thread (right after this email).
> Agree. Let's keep validation away for now and see in the future if it's
> really usefull and if/how it can be implemented.
Great.
> >o) VERSIONING AS PART OF THE BEHAVIOR URI
> >
> >The behavior URI *MUST* terminate with a /x.y that indicates the
> >major.minor version of the behavior that a block implements.
> >
> >On dependencies, each block must be able to specify the 'ranges' of
> >versioning that it is known to work with. For example
> >
> > <block behavior="http://xml.apache.org/forrest/skin/1.x";
> >prefix="skin"/>
> >
> >But I haven't really thought about the patterns that could be used for
> >this.
> >
> >Please, help on this.
> >
> >
>
> Once again, have you looked at Phoenix blocks ? The version of a block
> isn't in its name but as a separate attribute, and IIRC there are some
> features to check for version compatibility.
Yes, I'll report on cocoon/avalon block overlap soon.
> >o) OPTIONAL COP
> >
> >The block.info file makes it *optional* to expose behaviors or to depend
> >on them. This allows the COP model to nicely downgrade to the good old
> >single-archive WAR paradigm for those who don't care about block
> >polymorphism.
> >
> >
>
> This point is really important : people shouldn't have to package a COB
> and deploy it just to write a few pipelines. If a Processor
> implementation is used to mount blocks, this problem disappears as the
> current architecture is kept.
No, careful, I'm talking about something else here: you are stating that
COB (cocoon blocks) should be optional, while I was stating that COP
(component oriented programming) should be optional.
I agree that it should be possible to use Cocoon as we do today (read:
without knowing about blocks and application level componentization),
thus keeping back compatibility.
> >Possible Problems
> >-----------------
> >
> >1) classloading performance:
> >
> >since classloading will become more complicated, it will be slower, but
> >this will impact only the startup performance not the runtime
> >performance so no real issues here.
> >
> >
>
> Why will it be slower ? Because there's an additional classloader in the
> hierarchy ? As you say, this shouldn't be an issue.
Yep.
> >2) possible reduced portability of Cocoon:
> >
> >some servlet containers don't like servlets to come up with their own
> >classloaders. In those environments a block-enabled Cocoon might simply
> >not work. This doens't mean that Cocoon won't work, but that blocks
> >can't be deployed.
> >
> >NOTE: the next servlet API might fix that by requiring a better
> >classloading behavior by the containers.
> >
> >
>
> What about the note you wrote for the servlet JSR group ?
I didn't write it yet, but I'll do right away since there was no more
feedback.
> >3) difficult block interoperability
> >
> >without a way to automatically validate if a block implements a behavior
> >correctly, the type of that component is inherently weak and might lead
> >to problems that might become hard to fix.
> >
> >The block manager *must* be able to *clone* a block and let you modify
> >one clone without disturbine the other. [but these are implementation
> >details and we'll see in the future how serious this problem becomes. in
> >fact, sitemap pipelines aren't validated as well but nobody had enough
> >itch to scratch this]
> >
> >4) difficult transition
> >
> >When we have blocks, it's easy to imagine that will exist pure-code
> >blocks that wrap around libraries and provide only sitemap components
> >(think FOP, POI, Batik and so on).
> >
> >In that case, a 'naked Cocoon' becomes "de facto" back incompatible
> >because some sitemap components which are now included by default in
> >Cocoon) might not be present anymore, unless you wrap your code in
> >blocks and you depend explicitly on those blocks that expose that
> >specific behavior.
> >
> >So, some working is required.
> >
> >
>
> Is this really an issue ? People that want to use FOP or Batik without
> blocks can still put these blocks libs into the good old WEB-INF/lib to
> have the behaviour we have today.
Yes, but I was thinking about removing, say, the FOPSerializer class
implementation and place it inside the block.... but I see that, even if
architecturally cleaner, it might create more problems that those
solved.
> >This might force us to call a block-enabled Cocoon: Cocoon 3.0
> >
> >
>
> Or 2.2 if the architecture is backwards compatible, which seems to be
> possible.
Yes, it's possible. I agree.
> Sure this is a big thing ! Here are some additional random thoughts :
>
> How to "discover" available blocks to automatically update the structure
> of a portal site ?
I envision a cocoon block management interface which capable of
connecting to the central cocoon block library and check for updates of
the blocks currently deployed on the running Cocoon.
Note: nothing happens behind your back, just it prompts you that there
are newer compatible releases of the blocks you are currently using and
that he might feed them for you and install them. Given the advanced
classloading and request handling architecture we will need for blocks,
this could also be done at runtime without needing to stop the service
Cocoon provides (much like the asynchronous sitemap recompilation we
have).
> Will it be possible to have several blocks fulfilling the same contract
> in a single Cocoon instance?
Absolutely! Since all contact between blocks is performed at the
behavior level, it's Cocoon that knows what behavior instance is
connected to each block. In fact, during update, I think it will be wise
to make Cocoon keep an instance of the previous version of the block, so
that if something weird happens, you can always go back to the previous
version.
> For example, a site could use different
> skins depending on the user agent or depending on the location of the
> client (intranet / internet).
*NO*! that will definately break the elegance of the system! It should
be the skin's concern to *know* how to skin the site.
So, just like we are debating over at avalon-dev, you should *not* be
using 'hints' for block lookup since you should *not* be knowing
anything about the block you are depending from, except its behavior.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
