You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/10/03 17:20:08 UTC
[RT] Finishing the first phase of block design
I have updated the block design documents on the wiki. Changes were:
1) change /BLOCK-INF/ to /COB-INF/
2) change "cob:" back to "http:" for block URIs
[which URI range to use for blocks doesn't need to be identified at
this point, even if Ugo's suggestion to use
http://cocoon.apache.org/blocks is a good one so that it separates
naturally namespaces URIs from block URIs]
- o -
A few things are left to decide:
1) the block metadata information in the block.xml file
see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
2) how blocks expose classloading to other blocks
- o -
Descriptive Block metadata
--------------------------
The descriptive block metadata that we currently include is:
<name>***</name>
<description href="...">***</description>
<license href="..."/>***</license>
<author href="...">***</author>
where:
*** -> short text
... -> URL for reference
NOTE: I want to keep the above super simple. I know that <author> can
be generic and mapped to a person or group or entity... but at this
point, I think it's useless complexity.
This data will be used by the block librarian and by the block deployer
to catalogue and provide more information about this block. that's all.
I can't think of anything else I would like to know when choosing for a
block in a library of blocks.
Ah, remember that "certification" or any other metadata on the "status"
of the block is time dependent and therefore should *NOT* be included
in this file.
If you think you'd need more info, this is a good time to speak up.
Exposing classes
----------------
Stephen proposed to separate the classes to expose in a different jar
and expose that. I like this. It's simple and effective.
But instead of declaring classloaders or classpaths in the blocks, I
propose to extend the block FS layout so that we have
for individual classes and resources:
/classes
/classes/public
/classes/private
for jars:
/lib
/lib/public
/lib/private
the block manager will tranparently make available the classes found in
the "public" folders to the blocks that depend on this block (and
*ONLY* to those! classloading isolation is very important to achieve
hot deployment functionality without impacting the performance of a
running system too much)
the classloader will also check for conflicts: in fact, it will be
considered an error to depend on two blocks that provide one or more
classes with the same absolute name.
What do you think?
--
Stefano.
Re: [RT] Finishing the first phase of block design
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Geoff Howard wrote:
> I think it's not planned now or in future to explicitly describe these
> _in machine readable form_ (this does not preclude a document targeted
> at humans to describe what must be done or not done). The idea is that
> there are so many different shades of "contracts" that they could never
> really be described explicitly. By the way, this is almost a complete
> quote of what Stefano said at one point. I'm not claiming to be an
> authority on blocks - just regurgitating what I've taken in.
>
> What I'm musing about though is not qualitatively describing the
> behavior or resource, but just naming it or otherwise labeling it
> explicitly as exposed or not exposed. One option is to add it to the
> block.xml but I think this would be tedious if we also require a
> pipeline setup.
>
> However, Stefan Michels' proposal about declaring access modifiers on
> sitemap elements (he was referring to components but I'm specifically
> keying in on pipeline definitions) may be just the ticket: simple,
> declarative and clear. By the way, it is sort of analogous to the
> meta-info stuff at Avalon. The deploy process for a block may find it
> useful to assemble and organize information on which pipeline resources
> are publicly available, but that can be decided at implementation time.
>
Thanks for taking the time to answer my questions, Geoff.
> ----
>
> By the way, I forgot to add one more question on my list of musings:
>
> - Would even "internal-only" pipelines be protected as things stand now
> in the design?
>
> Geoff
Bye,
Andreas
Re: [RT] Finishing the first phase of block design
Posted by Geoff Howard <co...@leverageweb.com>.
Andreas Hochsteger wrote:
>
>
> Geoff Howard wrote:
>
>>
>> Exposing Resources
>> ------------------
>>
>> I'm adding this because my brain is still a little unsure about this.
>> So far, we've said that file resources (an xsl for example)
>>
>> 1) need to be exposed via a sitemap pipeline, even if only by a reader
>> 2) are not anywhere declared explicitly (except in the pipeline of
>> course)
>> 3) are not distinguised from resources meant to be private by any
>> formal semantics, though this information could be conveyed
>> human-to-human in any block docs (blocs? blockumentation? ;) ).
>>
>> Here are my oustanding questions:
>>
>> - Will we regret requiring the overhead of pipeline setup (runtime I
>> mean) for blocks which expose a great deal of otherwise static resources?
>> - Not found resources will have to go through every pipeline to
>> determine that it's not found. With fallback behavior due to
>> polymorphism this gets worse.
>> - Will not explicitly declaring which resources are meant to be public
>> cause trouble for block implementors and extenders?
>
>
> If a block provides resources (e.g. an XSL file) it also implicitely
> provides a contract for the use of this XSL file. This would be an XML
> document conforming to a certain schema (no matter if xsd, dtd, rng, ...).
>
> Until now I've not understood how you can describe this contract. Is it
> something we want to take care of now, or do we extend the explicit
> contracts, when we have some experiences with blocks to know how to deal
> with this issue.
>
> This can also affect other resources too:
> If you provide a skin block which another block extends, how can you
> make sure, that the logo has the size 80x80 pixels?
>
> There are surely many areas where it might make sense to explicitely
> describe those contracts, but I fail to see, if this is planned nor if
> we should take care about this now.
I think it's not planned now or in future to explicitly describe these
_in machine readable form_ (this does not preclude a document targeted
at humans to describe what must be done or not done). The idea is that
there are so many different shades of "contracts" that they could never
really be described explicitly. By the way, this is almost a complete
quote of what Stefano said at one point. I'm not claiming to be an
authority on blocks - just regurgitating what I've taken in.
What I'm musing about though is not qualitatively describing the
behavior or resource, but just naming it or otherwise labeling it
explicitly as exposed or not exposed. One option is to add it to the
block.xml but I think this would be tedious if we also require a
pipeline setup.
However, Stefan Michels' proposal about declaring access modifiers on
sitemap elements (he was referring to components but I'm specifically
keying in on pipeline definitions) may be just the ticket: simple,
declarative and clear. By the way, it is sort of analogous to the
meta-info stuff at Avalon. The deploy process for a block may find it
useful to assemble and organize information on which pipeline resources
are publicly available, but that can be decided at implementation time.
----
By the way, I forgot to add one more question on my list of musings:
- Would even "internal-only" pipelines be protected as things stand now
in the design?
Geoff
Re: [RT] Finishing the first phase of block design
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Geoff Howard wrote:
>
> Exposing Resources
> ------------------
>
> I'm adding this because my brain is still a little unsure about this. So
> far, we've said that file resources (an xsl for example)
>
> 1) need to be exposed via a sitemap pipeline, even if only by a reader
> 2) are not anywhere declared explicitly (except in the pipeline of course)
> 3) are not distinguised from resources meant to be private by any formal
> semantics, though this information could be conveyed human-to-human in
> any block docs (blocs? blockumentation? ;) ).
>
> Here are my oustanding questions:
>
> - Will we regret requiring the overhead of pipeline setup (runtime I
> mean) for blocks which expose a great deal of otherwise static resources?
> - Not found resources will have to go through every pipeline to
> determine that it's not found. With fallback behavior due to
> polymorphism this gets worse.
> - Will not explicitly declaring which resources are meant to be public
> cause trouble for block implementors and extenders?
If a block provides resources (e.g. an XSL file) it also implicitely
provides a contract for the use of this XSL file. This would be an XML
document conforming to a certain schema (no matter if xsd, dtd, rng, ...).
Until now I've not understood how you can describe this contract. Is it
something we want to take care of now, or do we extend the explicit
contracts, when we have some experiences with blocks to know how to deal
with this issue.
This can also affect other resources too:
If you provide a skin block which another block extends, how can you
make sure, that the logo has the size 80x80 pixels?
There are surely many areas where it might make sense to explicitely
describe those contracts, but I fail to see, if this is planned nor if
we should take care about this now.
Some enlightement would be appreciated.
Bye,
Andreas Hochsteger
http://highstick.blogspot.com/
Re: [RT] Finishing the first phase of block design
Posted by Geoff Howard <co...@leverageweb.com>.
Stefano Mazzocchi wrote:
>
> On Friday, Oct 10, 2003, at 04:01 Europe/Rome, Geoff Howard wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
>>>
>>>> Stefano Mazzocchi wrote:
...
>>>>> Exposing classes
>>>>> ----------------
>>>>> Stephen proposed to separate the classes to expose in a different
>>>>> jar and expose that. I like this. It's simple and effective.
>>>>> But instead of declaring classloaders or classpaths in the blocks,
>>>>> I propose to extend the block FS layout so that we have
>>>>> for individual classes and resources:
>>>>> /classes
>>>>> /classes/public
>>>>> /classes/private
>>>>> for jars:
>>>>> /lib
>>>>> /lib/public
>>>>> /lib/private
>>>>
>>>> Hmmm. That is quite different than what one would expect from the
>>>> WAR paradigm, no? Would
>>>>
>>>> COB-INF/[classes|lib]
>>>> COB-INF/public/[classes|lib]
>>>>
>>>> or
>>>>
>>>> COB-INF/private/[classes|lib]
>>>> COB-INF/public/[classes|lib]
>>>>
>>>> be any better?
>>>
>>> This might suggest the concept that private is the location of all
>>> the things that are private so
>>> private/lib
>>> means "I have libraries in the private section", so maybe I can put
>>> something else as well to have it protected? while
>>> lib/private
>>> means "these are the private libraries"... but doesn't say anything
>>> about non-lib things. I still like this approach better, even if it
>>> moves away from the WAR paradigm (which is not a big deal, IMO,
>>> since blocks are different enough already)
>>
>> Ok, that's a good point. I have a parallel concern that something like
>>
>> COB-INF/classes/com/mypackage/whyisntitfound/NotFound.class
>>
>> or
>>
>> package public.com.myconfused.package
>> public Class StillNotFound {...
>>
>> will pop up regularly on the users list.
>
> hmmm, don't think so, don't see many users actually adding their own
> single classes to those blocks and then deploy. I think they will put
> their prepackaged jars in there. but hey, you might be right.
>
>> One more idea to try to avert potential confusion.
>>
>> COB-INF/private-lib/
>> COB-INF/private-classes/
>> COB-INF/public-lib/
>> COB-INF/public-classes/
>>
>> ?
>
> I'm -0 on this, don't see the need, but I see your point.
Ok, if no one else sees the need I'm fine to move forward as is. As a
final wild idea, the Avalon meta-info project might help here.
...
>> 3) Explicit resource uri's
>> "Should exposed resource (pipeline) uri's be declared explicitly?"
>>
>> This is where I still have some reservations as begun above in the
>> not-found/fallback example.
>>
>> <map:match pattern="stylesheets/*.xslt">
>> <map:read src="styles/{1}.xslt"/>
>> </map:match>
>>
>> Is convenient to write, but may be inconvenient to use for block
>> users, extenders, implementers, and the BlockManager (code). Perhaps
>> the first can be taken care of with human readable documentation
>> (though I fear what the cocoon blocks will have in this respect).
>> Perhaps the second is unfounded. I'm not convinced of either of
>> those and think it merits further thinking.
>>
>> A possible solution:
>> Rather than disallowing wildcards, perhaps a part of block.xml could be
>>
>> <resources>
>> <uri>/stylesheets/news2html.xslt</uri>
>> ...
>> </resources>
>>
>> Maybe that'd be a pain but it'd leave no guessing. Maybe:
>>
>> ...
>> <extends block="http://yetanothercompany.com/skins/fancy/1.2.2">
>> <uri>/stylesheets/news2html.xslt</uri>
>> </extends>
>> ...
>>
>> Would be better? It would get rid of the fallback problem.
>
>
> I don't think we have a fallback problem if we stick to the concept
> that matching simply follows the sitemap rules and nothing else. If it
> works today and nobody complains I don't see why it should work there
> as well.
Ok, I see that. This will be another thing that should be clear in the
"idiots guide to authoring blocks" ("blocks for blockheads"?). Be
careful to match only what you intend to override by extension.
Geoff
Re: [RT] Finishing the first phase of block design
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 10, 2003, at 04:01 Europe/Rome, Geoff Howard wrote:
> Stefano Mazzocchi wrote:
>
>> On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
>>> Stefano Mazzocchi wrote:
>>>
>>>> I have updated the block design documents on the wiki. Changes were:
>>>
>>> ...
>>>
>>>> A few things are left to decide:
>>>> 1) the block metadata information in the block.xml file
>>>> see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
>>>> 2) how blocks expose classloading to other blocks
>
> ...
>
>>>> Exposing classes
>>>> ----------------
>>>> Stephen proposed to separate the classes to expose in a different
>>>> jar and expose that. I like this. It's simple and effective.
>>>> But instead of declaring classloaders or classpaths in the blocks,
>>>> I propose to extend the block FS layout so that we have
>>>> for individual classes and resources:
>>>> /classes
>>>> /classes/public
>>>> /classes/private
>>>> for jars:
>>>> /lib
>>>> /lib/public
>>>> /lib/private
>>>
>>> Hmmm. That is quite different than what one would expect from the
>>> WAR paradigm, no? Would
>>>
>>> COB-INF/[classes|lib]
>>> COB-INF/public/[classes|lib]
>>>
>>> or
>>>
>>> COB-INF/private/[classes|lib]
>>> COB-INF/public/[classes|lib]
>>>
>>> be any better?
>> This might suggest the concept that private is the location of all
>> the things that are private so
>> private/lib
>> means "I have libraries in the private section", so maybe I can put
>> something else as well to have it protected? while
>> lib/private
>> means "these are the private libraries"... but doesn't say anything
>> about non-lib things. I still like this approach better, even if it
>> moves away from the WAR paradigm (which is not a big deal, IMO, since
>> blocks are different enough already)
>
> Ok, that's a good point. I have a parallel concern that something like
>
> COB-INF/classes/com/mypackage/whyisntitfound/NotFound.class
>
> or
>
> package public.com.myconfused.package
> public Class StillNotFound {...
>
> will pop up regularly on the users list.
hmmm, don't think so, don't see many users actually adding their own
single classes to those blocks and then deploy. I think they will put
their prepackaged jars in there. but hey, you might be right.
> One more idea to try to avert potential confusion.
>
> COB-INF/private-lib/
> COB-INF/private-classes/
> COB-INF/public-lib/
> COB-INF/public-classes/
>
> ?
I'm -0 on this, don't see the need, but I see your point.
>>> - Not found resources will have to go through every pipeline to
>>> determine that it's not found. With fallback behavior due to
>>> polymorphism this gets worse.
>> I fail to see this, can you explain why you think this is the case?
>
> sitemap references:
> block:external-skin:/stylesheets/news2html.xslt
>
> block manager has external-skin ->
> http://mycompany.com/skins/corporate/34.3.345
> -> extends ->
> http://yetanothercompany.com/skins/fancy/1.2.2
>
> checks WEB-INF/blocks/384938958499/sitemap.xmap (by the way, the Cob
> samples at the wiki don't have sitemaps for the skins blocks which
> would presumably need them to expose their xslt in the example right?)
no, if the sitemap is not explicitly exposed, then the block manager
will default to sitemap.xmap in the root. if *that* is not present,
than the block does not expose resources and the block: protocol would
return a 404 or trigger an exception.
> If that sitemap doesn't override /stylesheets/news2html.xslt, every
> pipeline in that sitemap needs to be checked _then_ block manager goes
> on to
> WEB-INF/blocks/how-does-the-block-wiring-handle-blocks-extended-but-
> not-otherwise-used/sitemap.xmap
>
> if there are several levels of extension, this could be a long process.
true
> But now a worse thought comes to mind:
>
> suppose http://yetanothercompany.com/skins/fancy/1.2.2 has defined
>
> <map:match pattern="stylesheets/*.xslt">
> <map:read src="styles/{1}.xslt"/>
> </map:match>
>
> but http://mycompany.com/skins/corporate/34.3.345 only wants to
> override /stylesheets/news2html.xslt and /stylesheets/another.xslt
>
> if it is allowed it do
>
> <map:match pattern="stylesheets/*.xslt">
> <map:read src="mystyles/{1}.xslt"/>
> </map:match>
>
> then we must make the block manager and sitemap engine have a new
> behavior: if a match exists, but the source is not actually found,
> proceed to the super-block etc.
nono, inheritance works as the URI matching level, not at the resource
level. If you match the URI and then you failed to provide a resource,
you get a 404. So, at least, you know where you are.
> That's a mess, but so is having to set up a whole series of identical
> pipelines for every image, stylesheet, etc you need to override from a
> super-block, isn't it?
You can use regexp matching. It's not that bad.
I don't picture extension to change *everything* inside the block, but
just a few details. anti-patterns will emerge and verbosity of the
sitemap would reduce the change of abusing block extension.
> Now, perhaps this could be handled in other ways by using selectors
> instead of wildcards in matchers, but this could make writing a block
> a little finicky.
i think regexp matching is perfect for this
> If we decide to go with existing semantics with no explicit list of
> provided or overridden resources, we'll need to think through and very
> clearly document best practices that are not onerous. On users for
> whom this may be a very mindbending concept.
True, but as I said, it could have a useful side effect: you use
extension only when it really makes sense or forces you to think a
better (delegation oriented) refactoring pattern (extension is cool,
but should be used much less than delegation)
> Ok, there are several thoughts in all the above. Here they are with
> what is in my mind the state of the discussion:
>
> 1) Resource access
> "Should resources be provided via pipeline, via standard file i/o, or
> a combination of both?"
>
> I think we now all agree that pipeline-only is the way to go.
cool
> 2) Resource visibility
> "Should some ability to distinguish between public and private
> resources/pipelines exist?"
>
> Yes, and @block-access="public" handles this well presuming that
> discussion can be considered settled. (but see below)
all right
> 3) Explicit resource uri's
> "Should exposed resource (pipeline) uri's be declared explicitly?"
>
> This is where I still have some reservations as begun above in the
> not-found/fallback example.
>
> <map:match pattern="stylesheets/*.xslt">
> <map:read src="styles/{1}.xslt"/>
> </map:match>
>
> Is convenient to write, but may be inconvenient to use for block
> users, extenders, implementers, and the BlockManager (code). Perhaps
> the first can be taken care of with human readable documentation
> (though I fear what the cocoon blocks will have in this respect).
> Perhaps the second is unfounded. I'm not convinced of either of those
> and think it merits further thinking.
>
> A possible solution:
> Rather than disallowing wildcards, perhaps a part of block.xml could be
>
> <resources>
> <uri>/stylesheets/news2html.xslt</uri>
> ...
> </resources>
>
> Maybe that'd be a pain but it'd leave no guessing. Maybe:
>
> ...
> <extends block="http://yetanothercompany.com/skins/fancy/1.2.2">
> <uri>/stylesheets/news2html.xslt</uri>
> </extends>
> ...
>
> Would be better? It would get rid of the fallback problem.
I don't think we have a fallback problem if we stick to the concept
that matching simply follows the sitemap rules and nothing else. If it
works today and nobody complains I don't see why it should work there
as well.
--
Stefano.
Re: [RT] Finishing the first phase of block design
Posted by Geoff Howard <co...@leverageweb.com>.
Stefano Mazzocchi wrote:
>
> On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> I have updated the block design documents on the wiki. Changes were:
>>
>> ...
>>
>>> A few things are left to decide:
>>> 1) the block metadata information in the block.xml file
>>> see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
>>> 2) how blocks expose classloading to other blocks
...
>>> Exposing classes
>>> ----------------
>>> Stephen proposed to separate the classes to expose in a different jar
>>> and expose that. I like this. It's simple and effective.
>>> But instead of declaring classloaders or classpaths in the blocks, I
>>> propose to extend the block FS layout so that we have
>>> for individual classes and resources:
>>> /classes
>>> /classes/public
>>> /classes/private
>>> for jars:
>>> /lib
>>> /lib/public
>>> /lib/private
>>
>> Hmmm. That is quite different than what one would expect from the WAR
>> paradigm, no? Would
>>
>> COB-INF/[classes|lib]
>> COB-INF/public/[classes|lib]
>>
>> or
>>
>> COB-INF/private/[classes|lib]
>> COB-INF/public/[classes|lib]
>>
>> be any better?
>
>
> This might suggest the concept that private is the location of all the
> things that are private so
>
> private/lib
>
> means "I have libraries in the private section", so maybe I can put
> something else as well to have it protected? while
>
> lib/private
>
> means "these are the private libraries"... but doesn't say anything
> about non-lib things. I still like this approach better, even if it
> moves away from the WAR paradigm (which is not a big deal, IMO, since
> blocks are different enough already)
Ok, that's a good point. I have a parallel concern that something like
COB-INF/classes/com/mypackage/whyisntitfound/NotFound.class
or
package public.com.myconfused.package
public Class StillNotFound {...
will pop up regularly on the users list.
One more idea to try to avert potential confusion.
COB-INF/private-lib/
COB-INF/private-classes/
COB-INF/public-lib/
COB-INF/public-classes/
?
>>> the block manager will tranparently make available the classes found
>>> in the "public" folders to the blocks that depend on this block (and
>>> *ONLY* to those! classloading isolation is very important to achieve
>>> hot deployment functionality without impacting the performance of a
>>> running system too much)
>>
>> Is there never a way to avoid duplicating common jars between blocks?
>
> Avoid? well, not architecturally, that could means weird classloading
> issues.
>
>> I think we may be wise to go this way but I know this will be
>> unpopular and misunderstood and deserves some thought.
>
> good point, though.
>
>>> the classloader will also check for conflicts: in fact, it will be
>>> considered an error to depend on two blocks that provide one or more
>>> classes with the same absolute name.
>>
>> Hmmm. not sure I can mentally eliminate all valid cases at this
>> stage. Would there ever be an older version and a newer version of a
>> block deployed in the same space for example? (probably not but
>> thinking out loud)
>
> Oh, yeah, the above "modulo versioning". If the same class applies in
> blocks that differ only for their versions, it's good. The problem is
> when two completely different blocks do. (we might signal a warning
> instead of an error, but that's an implementation detail).
OK, sounds good.
>> Exposing Resources
>> ------------------
>>
>> I'm adding this because my brain is still a little unsure about this.
>> So far, we've said that file resources (an xsl for example)
>>
>> 1) need to be exposed via a sitemap pipeline, even if only by a reader
>> 2) are not anywhere declared explicitly (except in the pipeline of
>> course)
>> 3) are not distinguised from resources meant to be private by any
>> formal semantics, though this information could be conveyed
>> human-to-human in any block docs (blocs? blockumentation? ;) ).
>>
>> Here are my oustanding questions:
>>
>> - Will we regret requiring the overhead of pipeline setup (runtime I
>> mean) for blocks which expose a great deal of otherwise static resources?
>
> could be. remember though that the block: protocol will be caching
> friendly, so we might even gain performance.
>
>> - Not found resources will have to go through every pipeline to
>> determine that it's not found. With fallback behavior due to
>> polymorphism this gets worse.
>
> I fail to see this, can you explain why you think this is the case?
sitemap references:
block:external-skin:/stylesheets/news2html.xslt
block manager has external-skin ->
http://mycompany.com/skins/corporate/34.3.345
-> extends ->
http://yetanothercompany.com/skins/fancy/1.2.2
checks WEB-INF/blocks/384938958499/sitemap.xmap (by the way, the Cob
samples at the wiki don't have sitemaps for the skins blocks which would
presumably need them to expose their xslt in the example right?)
If that sitemap doesn't override /stylesheets/news2html.xslt, every
pipeline in that sitemap needs to be checked _then_ block manager goes
on to
WEB-INF/blocks/how-does-the-block-wiring-handle-blocks-extended-but-not-otherwise-used/sitemap.xmap
if there are several levels of extension, this could be a long process.
But now a worse thought comes to mind:
suppose http://yetanothercompany.com/skins/fancy/1.2.2 has defined
<map:match pattern="stylesheets/*.xslt">
<map:read src="styles/{1}.xslt"/>
</map:match>
but http://mycompany.com/skins/corporate/34.3.345 only wants to
override /stylesheets/news2html.xslt and /stylesheets/another.xslt
if it is allowed it do
<map:match pattern="stylesheets/*.xslt">
<map:read src="mystyles/{1}.xslt"/>
</map:match>
then we must make the block manager and sitemap engine have a new
behavior: if a match exists, but the source is not actually found,
proceed to the super-block etc. That's a mess, but so is having to set
up a whole series of identical pipelines for every image, stylesheet,
etc you need to override from a super-block, isn't it?
Now, perhaps this could be handled in other ways by using selectors
instead of wildcards in matchers, but this could make writing a block a
little finicky. If we decide to go with existing semantics with no
explicit list of provided or overridden resources, we'll need to think
through and very clearly document best practices that are not onerous.
On users for whom this may be a very mindbending concept.
>> - Will not explicitly declaring which resources are meant to be public
>> cause trouble for block implementors and extenders?
>
> ?? well, in the sitemap I can be very precise on what I want to expose.
> and everything else is not exposed. the sitemap is like a virtual file
> system description, powerful enough to describe all possible systems.
>
> If you have
>
> <pipeline block-access="public">
...
ah, that presupposes the block-access proposal which I think had just
hit the list when I wrote the above. I agree that helps.
>> Of course the flexibility of decoupling the uri space from the
>> filesystem is a benefit - but is it necessary?
>
> see above: I think so.
>
>> How hard is it really to keep filenames and directory locations for a
>> selected group of public resources?
>
> no, that's not the issue: the real issue is: if both resources and
> pipeline outputs are streams, why make a difference?
Ok, there are several thoughts in all the above. Here they are with
what is in my mind the state of the discussion:
1) Resource access
"Should resources be provided via pipeline, via standard file i/o, or a
combination of both?"
I think we now all agree that pipeline-only is the way to go.
2) Resource visibility
"Should some ability to distinguish between public and private
resources/pipelines exist?"
Yes, and @block-access="public" handles this well presuming that
discussion can be considered settled. (but see below)
3) Explicit resource uri's
"Should exposed resource (pipeline) uri's be declared explicitly?"
This is where I still have some reservations as begun above in the
not-found/fallback example.
<map:match pattern="stylesheets/*.xslt">
<map:read src="styles/{1}.xslt"/>
</map:match>
Is convenient to write, but may be inconvenient to use for block users,
extenders, implementers, and the BlockManager (code). Perhaps the first
can be taken care of with human readable documentation (though I fear
what the cocoon blocks will have in this respect). Perhaps the second
is unfounded. I'm not convinced of either of those and think it merits
further thinking.
A possible solution:
Rather than disallowing wildcards, perhaps a part of block.xml could be
<resources>
<uri>/stylesheets/news2html.xslt</uri>
...
</resources>
Maybe that'd be a pain but it'd leave no guessing. Maybe:
...
<extends block="http://yetanothercompany.com/skins/fancy/1.2.2">
<uri>/stylesheets/news2html.xslt</uri>
</extends>
...
Would be better? It would get rid of the fallback problem.
Geoff
Re: [RT] Finishing the first phase of block design
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Stefano Mazzocchi wrote:
>> - Will not explicitly declaring which resources are meant to be public
>> cause trouble for block implementors and extenders?
>
>
> ?? well, in the sitemap I can be very precise on what I want to expose.
> and everything else is not exposed. the sitemap is like a virtual file
> system description, powerful enough to describe all possible systems.
>
> If you have
>
> <pipeline block-access="public">
> <match pattern="**">
> <read src="public/{1}"/>
> </match>
> </pipeline>
>
> than the contract moves at the file system level, but that's up to you
> to decide.... and a block extender can do
>
> <pipeline block-access="public">
> <match pattern="stylesheet/layout2page.xslt">
> <generate type="sql" src="layout.xml"/>
> <transform src="layout2stylesheet.xslt"/>
> <serialize type="xml"/>
> </match>
> </pipeline>
>
> to provide extension that is procedural (but without exposing, for
> example layout.xml and layout2stylesheet.xslt which are just used
> internally)
>
> With a single mechanism, it's much easier to do meaningful block extension.
>
>> Of course the flexibility of decoupling the uri space from the
>> filesystem is a benefit - but is it necessary?
>
>
> see above: I think so.
>
>> How hard is it really to keep filenames and directory locations for a
>> selected group of public resources?
>
>
> no, that's not the issue: the real issue is: if both resources and
> pipeline outputs are streams, why make a difference?
>
I agree with Stefano at this point.
The independence of the physical filesystem layout is one of the best
features of Cocoon and it wouldn't be good to loose this great concept
for blocks.
> --
> Stefano.
>
Bye,
Andreas
Re: [RT] Finishing the first phase of block design
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 10, 2003, at 13:42 Europe/Rome, Stephan Michels wrote:
>
>
> On Fri, 10 Oct 2003, Stefano Mazzocchi wrote:
>
>>
>> On Friday, Oct 10, 2003, at 11:04 Europe/Rome, Stephan Michels wrote:
>>
>>>>>> Exposing classes
>>>>>> ----------------
>>>>>> Stephen proposed to separate the classes to expose in a different
>>>>>> jar
>>>>>> and expose that. I like this. It's simple and effective.
>>>>>> But instead of declaring classloaders or classpaths in the
>>>>>> blocks, I
>>>>>> propose to extend the block FS layout so that we have
>>>>>> for individual classes and resources:
>>>>>> /classes
>>>>>> /classes/public
>>>>>> /classes/private
>>>>>> for jars:
>>>>>> /lib
>>>>>> /lib/public
>>>>>> /lib/private
>>>>>
>>>>> Hmmm. That is quite different than what one would expect from the
>>>>> WAR
>>>>> paradigm, no? Would
>>>>>
>>>>> COB-INF/[classes|lib]
>>>>> COB-INF/public/[classes|lib]
>>>>>
>>>>> or
>>>>>
>>>>> COB-INF/private/[classes|lib]
>>>>> COB-INF/public/[classes|lib]
>>>>>
>>>>> be any better?
>>>
>>> Could you please explain, why we need to separate the classes and lib
>>> into
>>> private and public. For the developers POV, it will make the
>>> development
>>> more complicated, and doesn't see any benefit.
>>
>> to better isolate classloader and the contracts that are exposed by
>> the
>> block. make development more complicated but forces people to think of
>> application contracts that can be later reused as global behaviors.
>
> Your intentions are good, but do you really want to force them.
yes
> And how do you realize this. Do you what to cut the whole source
> path into two separate branches, or using javadoc statement.
it's just a matter of packaging the classes after having compiled them.
not such a big deal and, after all, a detail that each block developer
can take care of itself.
if he doensn't like peparation, he can stick everything into the public
part and forget about it... but shouldn't later come complianing if he
exposes public methods that were not really meant to be public.
>> think of it as a generalization of a collection of interfaces and data
>> structures that are passed around. like JAXP+Xerces jaxp is public,
>> xerces should not be, otherwise the public methods of the xerces
>> classes can be hooked up and later broken if a new implementation of
>> JAXP comes around.
>
> I doesn't think that a separation between private and public classes
> is quite easy.
Exactly. It forces to design your contracts. That's a good thing.
>> also reduces the potential problems with hot deployment for
>> classloading dependencies
>
> You will have the same problem, if you separates them into public and
> private. The classes, which are used by initiated objects, can't
> exchanged.
True, but the public zone will be done with mostly interfaces and data
models, the functional classes that are likely to change are
polymorphically managed by the component manager, you shouldn't be
calling "new object()" anyway, this is just done to expose the classes
that are created by the components.
remember that we are still forcing the people to use the basic avalon
component model of polymorphic delegation.
--
Stefano.
Re: [RT] Finishing the first phase of block design
Posted by Stephan Michels <st...@apache.org>.
On Fri, 10 Oct 2003, Stefano Mazzocchi wrote:
>
> On Friday, Oct 10, 2003, at 11:04 Europe/Rome, Stephan Michels wrote:
>
> >>>> Exposing classes
> >>>> ----------------
> >>>> Stephen proposed to separate the classes to expose in a different
> >>>> jar
> >>>> and expose that. I like this. It's simple and effective.
> >>>> But instead of declaring classloaders or classpaths in the blocks, I
> >>>> propose to extend the block FS layout so that we have
> >>>> for individual classes and resources:
> >>>> /classes
> >>>> /classes/public
> >>>> /classes/private
> >>>> for jars:
> >>>> /lib
> >>>> /lib/public
> >>>> /lib/private
> >>>
> >>> Hmmm. That is quite different than what one would expect from the
> >>> WAR
> >>> paradigm, no? Would
> >>>
> >>> COB-INF/[classes|lib]
> >>> COB-INF/public/[classes|lib]
> >>>
> >>> or
> >>>
> >>> COB-INF/private/[classes|lib]
> >>> COB-INF/public/[classes|lib]
> >>>
> >>> be any better?
> >
> > Could you please explain, why we need to separate the classes and lib
> > into
> > private and public. For the developers POV, it will make the
> > development
> > more complicated, and doesn't see any benefit.
>
> to better isolate classloader and the contracts that are exposed by the
> block. make development more complicated but forces people to think of
> application contracts that can be later reused as global behaviors.
Your intentions are good, but do you really want to force them.
And how do you realize this. Do you what to cut the whole source
path into two separate branches, or using javadoc statement.
> think of it as a generalization of a collection of interfaces and data
> structures that are passed around. like JAXP+Xerces jaxp is public,
> xerces should not be, otherwise the public methods of the xerces
> classes can be hooked up and later broken if a new implementation of
> JAXP comes around.
I doesn't think that a separation between private and public classes
is quite easy.
> also reduces the potential problems with hot deployment for
> classloading dependencies
You will have the same problem, if you separates them into public and
private. The classes, which are used by initiated objects, can't
exchanged.
Stephan Michels.
RE: [RT] Finishing the first phase of block design
Posted by Robert Koberg <ro...@koberg.com>.
> to better isolate classloader and the contracts that are exposed by the
> block. make development more complicated but forces people to think of
> application contracts that can be later reused as global behaviors.
>
> think of it as a generalization of a collection of interfaces and data
> structures that are passed around. like JAXP+Xerces jaxp is public,
> xerces should not be, otherwise the public methods of the xerces
> classes can be hooked up and later broken if a new implementation of
> JAXP comes around.
I posted the text below to the XSL list a few weeks ago (can't find it in
the archives). Mike Kay responded saying the JAXP working group was
reviewing these issues now and would perhaps come up with clearer
specificiations. Cocoon, specifically, might be interested in the
Xalan/XSLTC part below.
<the post>
I want to report my findings with regard to standard implementations of how
the method setURIReolver works in the popular Open Source java xsl
processors. From what I understand from past discussions is that the spec is
not clear on the issue. I was wondering if processor developers could get
together and decide either one way to implement the setURIResolver or do it
the way Saxon does by doing both (hopefully explained below).
According to most API's you can set the URIResolver on the
TransformerFactory and on the Transformer. Generally, the resolver set on
the TransformerFactory resolves xsl:includes and xsl:imports. If set on the
Tranformer it resolves document() function calls.
- Saxon allows you to set the resolver on the TransformerFactory to resolve
both includes/imports and document().
It also lets you set one for the factory and one for the transformer. When
this is done the factory resolves include/import and the transformer
resolves document(). This is the best way, IMHO.
- jd.xslt only uses the TransformerFactory to be used for
xsl:include/xsl:import and document() resolution.
Strangely, the standard xalan and it's xsltc implementation do two different
things.
- standard xalan requires you to use the TransformerFactory for xsl:include
and xsl:import and the Transformer for document()
- xsltc xalan uses the TransformerFactory for both xsl:include/xsl:import
and document() -- not the Transformer for document(), like the standard
xalan.
Any chance of standardizing on one way? :)
</the post>
Best,
-Rob
>
> also reduces the potential problems with hot deployment for
> classloading dependencies
>
> --
> Stefano.
Re: [RT] Finishing the first phase of block design
Posted by Stefano Mazzocchi <st...@apache.org>.
On Friday, Oct 10, 2003, at 11:04 Europe/Rome, Stephan Michels wrote:
>
>
> On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
>
>>
>> On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>> I have updated the block design documents on the wiki. Changes were:
>>>
>>> ...
>>>
>>>> A few things are left to decide:
>>>> 1) the block metadata information in the block.xml file
>>>> see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
>>>> 2) how blocks expose classloading to other blocks
>>>> - o -
>>>> Descriptive Block metadata
>>>> --------------------------
>>>> The descriptive block metadata that we currently include is:
>>>> <name>***</name>
>>>> <description href="...">***</description>
>>>> <license href="..."/>***</license>
>>>> <author href="...">***</author>
>>>
>>> +1
>>>
>>> Andreas suggested version number which is really handled already in
>>> the block id and release date. I think a date though may be a useful
>>> additional piece of info.
>>
>> Good point.
>
> IMHO, I would try first a solution, which doesn't introduce a new
> descriptor.
like what?
> In a know german XML magazin, Cocoon was descriped a
> configuration hell, and as a anti pattern using XML as
> configuration format.
yeah, we agree about the configuration hell, but this is because we
expose too much of things that people should never touch.
>
> So my proposal would be to start small, and if there isn't a way
> to come forward with the current possibilities, then
> we could introduce a new descriptor file beside
> cocoon.xconf/sitemap.xmap/web.xml etc.
you didn't get it: the is the *block* descriptor. each block needs one.
I see no way to go without one.
>>>> Exposing classes
>>>> ----------------
>>>> Stephen proposed to separate the classes to expose in a different
>>>> jar
>>>> and expose that. I like this. It's simple and effective.
>>>> But instead of declaring classloaders or classpaths in the blocks, I
>>>> propose to extend the block FS layout so that we have
>>>> for individual classes and resources:
>>>> /classes
>>>> /classes/public
>>>> /classes/private
>>>> for jars:
>>>> /lib
>>>> /lib/public
>>>> /lib/private
>>>
>>> Hmmm. That is quite different than what one would expect from the
>>> WAR
>>> paradigm, no? Would
>>>
>>> COB-INF/[classes|lib]
>>> COB-INF/public/[classes|lib]
>>>
>>> or
>>>
>>> COB-INF/private/[classes|lib]
>>> COB-INF/public/[classes|lib]
>>>
>>> be any better?
>
> Could you please explain, why we need to separate the classes and lib
> into
> private and public. For the developers POV, it will make the
> development
> more complicated, and doesn't see any benefit.
to better isolate classloader and the contracts that are exposed by the
block. make development more complicated but forces people to think of
application contracts that can be later reused as global behaviors.
think of it as a generalization of a collection of interfaces and data
structures that are passed around. like JAXP+Xerces jaxp is public,
xerces should not be, otherwise the public methods of the xerces
classes can be hooked up and later broken if a new implementation of
JAXP comes around.
also reduces the potential problems with hot deployment for
classloading dependencies
--
Stefano.
Re: [RT] Finishing the first phase of block design
Posted by Stephan Michels <st...@apache.org>.
On Thu, 9 Oct 2003, Stefano Mazzocchi wrote:
>
> On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
>
> > Stefano Mazzocchi wrote:
> >
> >> I have updated the block design documents on the wiki. Changes were:
> >
> > ...
> >
> >> A few things are left to decide:
> >> 1) the block metadata information in the block.xml file
> >> see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
> >> 2) how blocks expose classloading to other blocks
> >> - o -
> >> Descriptive Block metadata
> >> --------------------------
> >> The descriptive block metadata that we currently include is:
> >> <name>***</name>
> >> <description href="...">***</description>
> >> <license href="..."/>***</license>
> >> <author href="...">***</author>
> >
> > +1
> >
> > Andreas suggested version number which is really handled already in
> > the block id and release date. I think a date though may be a useful
> > additional piece of info.
>
> Good point.
IMHO, I would try first a solution, which doesn't introduce a new
descriptor. In a know german XML magazin, Cocoon was descriped a
configuration hell, and as a anti pattern using XML as
configuration format.
So my proposal would be to start small, and if there isn't a way
to come forward with the current possibilities, then
we could introduce a new descriptor file beside
cocoon.xconf/sitemap.xmap/web.xml etc.
> >> Exposing classes
> >> ----------------
> >> Stephen proposed to separate the classes to expose in a different jar
> >> and expose that. I like this. It's simple and effective.
> >> But instead of declaring classloaders or classpaths in the blocks, I
> >> propose to extend the block FS layout so that we have
> >> for individual classes and resources:
> >> /classes
> >> /classes/public
> >> /classes/private
> >> for jars:
> >> /lib
> >> /lib/public
> >> /lib/private
> >
> > Hmmm. That is quite different than what one would expect from the WAR
> > paradigm, no? Would
> >
> > COB-INF/[classes|lib]
> > COB-INF/public/[classes|lib]
> >
> > or
> >
> > COB-INF/private/[classes|lib]
> > COB-INF/public/[classes|lib]
> >
> > be any better?
Could you please explain, why we need to separate the classes and lib into
private and public. For the developers POV, it will make the development
more complicated, and doesn't see any benefit.
> > Exposing Resources
> > ------------------
> >
> > I'm adding this because my brain is still a little unsure about this.
> > So far, we've said that file resources (an xsl for example)
> >
> > 1) need to be exposed via a sitemap pipeline, even if only by a reader
> > 2) are not anywhere declared explicitly (except in the pipeline of
> > course)
> > 3) are not distinguised from resources meant to be private by any
> > formal semantics, though this information could be conveyed
> > human-to-human in any block docs (blocs? blockumentation? ;) ).
> >
> > Here are my oustanding questions:
> >
> > - Will we regret requiring the overhead of pipeline setup (runtime I
> > mean) for blocks which expose a great deal of otherwise static
> > resources?
>
> could be. remember though that the block: protocol will be caching
> friendly, so we might even gain performance.
>
> > - Not found resources will have to go through every pipeline to
> > determine that it's not found. With fallback behavior due to
> > polymorphism this gets worse.
>
> I fail to see this, can you explain why you think this is the case?
>
> > - Will not explicitly declaring which resources are meant to be public
> > cause trouble for block implementors and extenders?
>
> ?? well, in the sitemap I can be very precise on what I want to expose.
> and everything else is not exposed. the sitemap is like a virtual file
> system description, powerful enough to describe all possible systems.
>
> If you have
>
> <pipeline block-access="public">
> <match pattern="**">
> <read src="public/{1}"/>
> </match>
> </pipeline>
>
> than the contract moves at the file system level, but that's up to you
> to decide.... and a block extender can do
>
> <pipeline block-access="public">
> <match pattern="stylesheet/layout2page.xslt">
> <generate type="sql" src="layout.xml"/>
> <transform src="layout2stylesheet.xslt"/>
> <serialize type="xml"/>
> </match>
> </pipeline>
>
> to provide extension that is procedural (but without exposing, for
> example layout.xml and layout2stylesheet.xslt which are just used
> internally)
Yes, I like that. This is the solution, which comes first in my mind.
Stephan.
Re: [RT] Finishing the first phase of block design
Posted by Stefano Mazzocchi <st...@apache.org>.
On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:
> Stefano Mazzocchi wrote:
>
>> I have updated the block design documents on the wiki. Changes were:
>
> ...
>
>> A few things are left to decide:
>> 1) the block metadata information in the block.xml file
>> see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
>> 2) how blocks expose classloading to other blocks
>> - o -
>> Descriptive Block metadata
>> --------------------------
>> The descriptive block metadata that we currently include is:
>> <name>***</name>
>> <description href="...">***</description>
>> <license href="..."/>***</license>
>> <author href="...">***</author>
>
> +1
>
> Andreas suggested version number which is really handled already in
> the block id and release date. I think a date though may be a useful
> additional piece of info.
Good point.
>> Ah, remember that "certification" or any other metadata on the
>> "status" of the block is time dependent and therefore should *NOT* be
>> included in this file.
>
> Yup.
>
>> Exposing classes
>> ----------------
>> Stephen proposed to separate the classes to expose in a different jar
>> and expose that. I like this. It's simple and effective.
>> But instead of declaring classloaders or classpaths in the blocks, I
>> propose to extend the block FS layout so that we have
>> for individual classes and resources:
>> /classes
>> /classes/public
>> /classes/private
>> for jars:
>> /lib
>> /lib/public
>> /lib/private
>
> Hmmm. That is quite different than what one would expect from the WAR
> paradigm, no? Would
>
> COB-INF/[classes|lib]
> COB-INF/public/[classes|lib]
>
> or
>
> COB-INF/private/[classes|lib]
> COB-INF/public/[classes|lib]
>
> be any better?
This might suggest the concept that private is the location of all the
things that are private so
private/lib
means "I have libraries in the private section", so maybe I can put
something else as well to have it protected? while
lib/private
means "these are the private libraries"... but doesn't say anything
about non-lib things. I still like this approach better, even if it
moves away from the WAR paradigm (which is not a big deal, IMO, since
blocks are different enough already)
>> the block manager will tranparently make available the classes found
>> in the "public" folders to the blocks that depend on this block (and
>> *ONLY* to those! classloading isolation is very important to achieve
>> hot deployment functionality without impacting the performance of a
>> running system too much)
>
> Is there never a way to avoid duplicating common jars between blocks?
Avoid? well, not architecturally, that could means weird classloading
issues.
> I think we may be wise to go this way but I know this will be
> unpopular and misunderstood and deserves some thought.
good point, though.
>> the classloader will also check for conflicts: in fact, it will be
>> considered an error to depend on two blocks that provide one or more
>> classes with the same absolute name.
>
> Hmmm. not sure I can mentally eliminate all valid cases at this
> stage. Would there ever be an older version and a newer version of a
> block deployed in the same space for example? (probably not but
> thinking out loud)
Oh, yeah, the above "modulo versioning". If the same class applies in
blocks that differ only for their versions, it's good. The problem is
when two completely different blocks do. (we might signal a warning
instead of an error, but that's an implementation detail).
> Exposing Resources
> ------------------
>
> I'm adding this because my brain is still a little unsure about this.
> So far, we've said that file resources (an xsl for example)
>
> 1) need to be exposed via a sitemap pipeline, even if only by a reader
> 2) are not anywhere declared explicitly (except in the pipeline of
> course)
> 3) are not distinguised from resources meant to be private by any
> formal semantics, though this information could be conveyed
> human-to-human in any block docs (blocs? blockumentation? ;) ).
>
> Here are my oustanding questions:
>
> - Will we regret requiring the overhead of pipeline setup (runtime I
> mean) for blocks which expose a great deal of otherwise static
> resources?
could be. remember though that the block: protocol will be caching
friendly, so we might even gain performance.
> - Not found resources will have to go through every pipeline to
> determine that it's not found. With fallback behavior due to
> polymorphism this gets worse.
I fail to see this, can you explain why you think this is the case?
> - Will not explicitly declaring which resources are meant to be public
> cause trouble for block implementors and extenders?
?? well, in the sitemap I can be very precise on what I want to expose.
and everything else is not exposed. the sitemap is like a virtual file
system description, powerful enough to describe all possible systems.
If you have
<pipeline block-access="public">
<match pattern="**">
<read src="public/{1}"/>
</match>
</pipeline>
than the contract moves at the file system level, but that's up to you
to decide.... and a block extender can do
<pipeline block-access="public">
<match pattern="stylesheet/layout2page.xslt">
<generate type="sql" src="layout.xml"/>
<transform src="layout2stylesheet.xslt"/>
<serialize type="xml"/>
</match>
</pipeline>
to provide extension that is procedural (but without exposing, for
example layout.xml and layout2stylesheet.xslt which are just used
internally)
With a single mechanism, it's much easier to do meaningful block
extension.
> Of course the flexibility of decoupling the uri space from the
> filesystem is a benefit - but is it necessary?
see above: I think so.
> How hard is it really to keep filenames and directory locations for a
> selected group of public resources?
no, that's not the issue: the real issue is: if both resources and
pipeline outputs are streams, why make a difference?
--
Stefano.
Re: [RT] Finishing the first phase of block design
Posted by Geoff Howard <co...@leverageweb.com>.
Stefano Mazzocchi wrote:
> I have updated the block design documents on the wiki. Changes were:
...
> A few things are left to decide:
>
> 1) the block metadata information in the block.xml file
>
> see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
>
> 2) how blocks expose classloading to other blocks
>
> - o -
>
> Descriptive Block metadata
> --------------------------
>
> The descriptive block metadata that we currently include is:
>
> <name>***</name>
>
> <description href="...">***</description>
>
> <license href="..."/>***</license>
>
> <author href="...">***</author>
+1
Andreas suggested version number which is really handled already in the
block id and release date. I think a date though may be a useful
additional piece of info.
> Ah, remember that "certification" or any other metadata on the "status"
> of the block is time dependent and therefore should *NOT* be included in
> this file.
Yup.
> Exposing classes
> ----------------
>
> Stephen proposed to separate the classes to expose in a different jar
> and expose that. I like this. It's simple and effective.
>
> But instead of declaring classloaders or classpaths in the blocks, I
> propose to extend the block FS layout so that we have
>
> for individual classes and resources:
> /classes
> /classes/public
> /classes/private
>
> for jars:
> /lib
> /lib/public
> /lib/private
Hmmm. That is quite different than what one would expect from the WAR
paradigm, no? Would
COB-INF/[classes|lib]
COB-INF/public/[classes|lib]
or
COB-INF/private/[classes|lib]
COB-INF/public/[classes|lib]
be any better?
> the block manager will tranparently make available the classes found in
> the "public" folders to the blocks that depend on this block (and *ONLY*
> to those! classloading isolation is very important to achieve hot
> deployment functionality without impacting the performance of a running
> system too much)
Is there never a way to avoid duplicating common jars between blocks? I
think we may be wise to go this way but I know this will be unpopular
and misunderstood and deserves some thought.
> the classloader will also check for conflicts: in fact, it will be
> considered an error to depend on two blocks that provide one or more
> classes with the same absolute name.
Hmmm. not sure I can mentally eliminate all valid cases at this stage.
Would there ever be an older version and a newer version of a block
deployed in the same space for example? (probably not but thinking out loud)
Exposing Resources
------------------
I'm adding this because my brain is still a little unsure about this.
So far, we've said that file resources (an xsl for example)
1) need to be exposed via a sitemap pipeline, even if only by a reader
2) are not anywhere declared explicitly (except in the pipeline of course)
3) are not distinguised from resources meant to be private by any formal
semantics, though this information could be conveyed human-to-human in
any block docs (blocs? blockumentation? ;) ).
Here are my oustanding questions:
- Will we regret requiring the overhead of pipeline setup (runtime I
mean) for blocks which expose a great deal of otherwise static resources?
- Not found resources will have to go through every pipeline to
determine that it's not found. With fallback behavior due to
polymorphism this gets worse.
- Will not explicitly declaring which resources are meant to be public
cause trouble for block implementors and extenders?
Of course the flexibility of decoupling the uri space from the
filesystem is a benefit - but is it necessary? How hard is it really to
keep filenames and directory locations for a selected group of public
resources?
Perhaps though there's a best of both worlds. The last two issues may
be answered by Stefan's sitemap access modifier RT?
Say "hi" to Ghent,
Geoff
Re: [RT] Finishing the first phase of block design
Posted by Andreas Hochsteger <e9...@student.tuwien.ac.at>.
Stefano Mazzocchi wrote:
> Descriptive Block metadata
> --------------------------
>
> The descriptive block metadata that we currently include is:
>
> <name>***</name>
>
> <description href="...">***</description>
>
> <license href="..."/>***</license>
>
> <author href="...">***</author>
>
> where:
>
> *** -> short text
> ... -> URL for reference
>
> NOTE: I want to keep the above super simple. I know that <author> can be
> generic and mapped to a person or group or entity... but at this point,
> I think it's useless complexity.
>
> This data will be used by the block librarian and by the block deployer
> to catalogue and provide more information about this block. that's all.
>
> I can't think of anything else I would like to know when choosing for a
> block in a library of blocks.
>
> Ah, remember that "certification" or any other metadata on the "status"
> of the block is time dependent and therefore should *NOT* be included in
> this file.
>
> If you think you'd need more info, this is a good time to speak up.
Don't know, if it fits into this file but here is some more information
I can think of:
* Version number
* Release date
> Exposing classes
> ----------------
>
> Stephen proposed to separate the classes to expose in a different jar
> and expose that. I like this. It's simple and effective.
>
> But instead of declaring classloaders or classpaths in the blocks, I
> propose to extend the block FS layout so that we have
>
> for individual classes and resources:
> /classes
> /classes/public
> /classes/private
>
> for jars:
> /lib
> /lib/public
> /lib/private
>
> the block manager will tranparently make available the classes found in
> the "public" folders to the blocks that depend on this block (and *ONLY*
> to those! classloading isolation is very important to achieve hot
> deployment functionality without impacting the performance of a running
> system too much)
>
> the classloader will also check for conflicts: in fact, it will be
> considered an error to depend on two blocks that provide one or more
> classes with the same absolute name.
>
> What do you think?
That's a very simple and easy-to-understand approach.
It does just what you need without hidden magic.
I like it :-)
> --
> Stefano.
Bye,
Andreas