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
