Hi, I guess that adding practical examples and consequences to the suggestions will help discussing the concepts at a broader scale. I just love examples that can be torn in half and rebuild.
Ok, asbestos underwear in position - here we go: 1.) We want easily deployable packages, just like .war or .ear files in other contexts. For Cocoon, this would be .cwa files; I guess it's just a zip file with some information relating to the package, like a MANIFEST in a .jar file. I would consider this extra information to be at least a sitemap.xmap that controls the sub-URI-space of the package. 2.) We want these easily deployable .cwa packages to be self-contained. I consider modifying a package for setup issues impractical, so the setup for a package should happen outside of the package. Inversion of control, Avalon principle ;). At the same time this allows a single .cwa package file to be setup and deployed at multiple places at the same time. Some setup like mounting could happen in a sitemap.xmap, as currently this is the place controlling URI space; this even allows for an auto-mounting extension for the sitemap. Many packages will require setup beyond mounting, for example where to find the corporate identity stylesheets, which accounting database to use, or what's the business name to be put on the tax report thats being produced, so I need both the information about what I CAN configure and what I actually DO configure for this package. I think of the former as sort of a standardized setup-info.xml or the like regulary contained in .cwa packages that have something to be configured. The latter could be an configuration file positioned somewhere near the sitemap.xmap and cocoon.xconf files in the filesystem. One might even refer to the configuration file from the sitemap, so the way the configuration files are being organized is left as a choice to the system administrator. 3.) As the .cwa package does not know in advance where it will be deployed, it cannot know about the URI space it will be accessable from via the web, yet most content needs to point to other content in this package, for example just simple links from HTML page A to HTML page B. If resource names of pipelines were added to the sitemap which are local to the package/sitemap, the .cwa designer could just use resource names in his package and have them resolved later via taglibs in a page or other means in the sitemap like a cocoon-protocol extension like it was posted for role-based access. 4.) .cwa packages will rarely be on their own, not interconnecting. So resource naming would need to work between .cwa packages. Giving each deployed .cwa package a global name, the local resource name for a pipeline could be referenced from another position. I guess there are plenty of opportunities to discuss what can be done better or easier differently, so let's hear them. Best regards, Michael Hartle --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
