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
