On Sat, 6 Oct 2001, Stefano Mazzocchi wrote: > This thread is become really good. > > Michael Hartle wrote: > > > > 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: > > Sam, seems like people liked this expression very much :)
:) > > > 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. > > I share your vision totally. > > > 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. > > Ditto. > > > 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. > > Again, I was thinking about IoC: have the CWA ask Cocoon about things it > needs instead of having you to modify the things after setup. I thought IoC is working the other way: have Cocoon tell the CWA about those things. > > > 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. > > I recently came to know MacOSX NetInfo package and found it *very* > elegant (much more elegant than the 30-years old /etc directory, > anyway): it's a short of directory server that contains configuration. A > sort of elegant and simple configuration registry (unlike windows') that > is used to "serve" configurations to who it requires them. > > It provides a central point of configuration and an easy way to deploy > something without having to modify it. I've recently discussed this with other people. A central point of configuration is essential especially if you have to manage a distributed environment. Giacomo > The contract is the internal tree shape (sort of URI space for > configurations) and CWA might look for configurations in there. For > example in a sitemap > > <map:parameter name="database" > value="conf://datasource/relational/main"/> > <map:parameter name="user" > value="conf://datasource/relational/main/user"/> > <map:parameter name="password" > value="conf://datasource/relational/main/password"/> > > something like that. > > It is also pretty easy to scan the CWA for conf:// protocols and > understand if the registry contains already the information or needs to > prompt the installer for it. > > This way, security sensible information is stored by Cocoon in another > location, probably out of the addressing space, making it inherently > more secure (it might even attach directly to an LDAP server, for that > matter). > > > 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. > > I'd assume that the URI structure of the CWA package can be considered a > contract. So, the only "soft" thing is the location where this "hard" > URI tree is mounted. > > > 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. > > Exactly, we still have to define "how" those "soft"+"hard" links are > actually translated to real URL addresses, but we agree on the mechanism > and this is a good thing. > > > 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. > > You touch another important point here: if on one hand, addressing by > role must not sacrifice the ability to have multiple instances for the > same role, on the other hand, must be precise enough to avoid name > collisions. > > This is the same problem faced by by both java dynamic loading and xml > namespaces: both use URI's as unique identification. > > Avalon, for example, uses the inverse dot notation (in short, the > interface name, i.e. org.apache.cocoon.component.Parser) to create > unique behaviors identified by the interface that represent them. > > Same thing for namespaces, in fact the xmlns attribute is a way to > reduce verbosity but doesn't change the nature of the internal infoset > which assumes that all elements are prefixed with the URI that uniquely > reference them. > > So, each CWA must indicate both: > > o its unique role > o its instance identifier > > For example, a webmail CWA could be identified by > > http://apache.org/cocoon/webapp/webmail > My Fancy WebApp 2.3 > > Now, the problem is that we cannot impose the use of something like > > cocoon://[http://apache.org/cocoon/webapp]/some/resource > > but one solution would be use (abuse?) the XML namespace mechanism > > <element xmlns:webmail="http://apache.org/cocoon/webapp"; > href="cocoon://webmail/some/resource"/> > > where we extend the default namespace behavior to do namespace > resolution even inside the attribute content. In fact, even XSLT does so > when doing > > <xsl:template match="ns:element" xmlns:ns="..."> > > and ns: is matched not by the prefix, but by the expanded namespace URI. > > As far as uniqueness is concerned, the above mechanism works, but if we > want to allow more than one instance of the same role, we could indicate > so like this: > > <element xmlns:webmail="http://apache.org/cocoon/webapp"; > href="cocoon://webmail:mywebapp/some/resource"/> > > But this creates a composition problem: one CWA must know in advance the > instance-specific name of the other CWA. Since this is controlled by the > CWA deployer and cannot be hardcoded (unless we accept name collisions), > this is a weak contract and it's very likely to break everything very > soon. (with a very hard time figuring out what to do). > > So, here is my solution (that closely follows the strategy we designed > for Avalon blocks): > > each CWA indicates > o its role as a URI (http://apache.org/cocoon/webapp) > o its name as a human readable form (My Fancy Webapp) > o its version as major.minor format (2.3) > o its dependancies on other CWA (role:version) > o its dependencies on external configurations > > when the CWA is deployed, the following things happen: > > 1) the CWA deployment descriptor is read > > 2) a machine specific name is given to the deployed instance. (if > another CWA of the same role:version pair is already in place, the > instance name must be unique, for example, adding a counter at the end > such as "http://apache.org/cocoon/webapp:2.3:2"; > > 3) for each CWA dependancy do: > 3.a) check if a CWA with that role is already in place. > 3.b) if so > 3.b.i) if only instance of that role, map the role to that instance. > 3.b.ii) otherwise, prompt the deployer and ask for which available > instance should be associated to that role. > 3.c) otherwise, use the role URI to download the required CWA [we can > define how this is done later] and deploy it. > > 4) for each configuration dependancy do: > 4.a) check if the configuration key already exists in the conf > registry > 4.a.i) if so, prompt the user if the available value is ok > 4.a.i.1) if so, go on > 4.a.i.2) otherwise, change the value associated to that > configuration and relative to that instance only. > 4.a.ii) otherwise, prompt the deployer for the conf value > > 5) the deployer is finally asked for a URI location to mount the CWA > instance. > > NOTE: > > 1) possible recursive dependancies might create a deadlock on the > deployment phase, expecially when the Cocoon container is initially > empty. This is unlikely to happen for well designed components, but we > can download and scan all required CWA for deadlocks before actually do > any real deployment so that problems can be stopped *before* entering > the system. > > 2) if more than one instance of a single webapp is available, the conf > registry must be smart enough to lookup a configuration based not only > on the requested path but also on the webapp instance that has requested > it. This avoid collisions due to the fact that different instances of > the same role by definition share the same configuration needs. > > > I guess there are plenty of opportunities to discuss what can be done > > better or easier differently, so let's hear them. > > The only thing that is left to discuss is how (who does it and at what > level) the address translation between roled-based access and real URI > address is performed. > > Everything else looks in pretty good design shape to me, but of course, > comments are more than welcome. > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
