On Sun, 7 Oct 2001, Michael Hartle wrote: > Stefano Mazzocchi wrote: > > >>Ok, asbestos underwear in position - here we go: > >> > >Sam, seems like people liked this expression very much :) > > > It was sort of an inspiring picture, I admit ;) > > >>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. > > > Oh, I am not thinking of modifying the CWA for any purpose, I simply > meant supplying Cocoon with configuration information it would pass on > to the CWA when appropriate. I am interpreting the IoC principle the > other way around; the CWA is "just" a web application among many others > that are also being some sort of drop-in. So it is not the CWA > actively/dynamically asking Cocoon about something, but Cocoon handing > down configuration information to the CWA at a certain stage.
Exactly my thought :) > > >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). > > > The concept of allowing different sources (LDAP, filesystem, etc) for > configuration as described is interesting, although I do think that each > application should have it's own dedicated branch for setup information > instead of forcing each parameter to be explicitly being passed; as > large CWAs are going to happen (they will, right ?), the sheer length of > the list of "parameters" for customizing them could well justify this > approach. > > This would even allow passing on an instance of configuration source to > the CWA, this instance implementing some ConfigurationSource-interface - > be aware that I am not sure whether such an interface or class with this > name is already existing, and I am not knowingly referring to anything > here as I just made a wild guess how this could be named. This might be > an LDAPConfigurationSource or a FileConfigurationSource, being able to > deliver arbitrary configuration information to the CWA as a stream of > SAX events. And those ConfigurationSource's could be defined in the > sitemap and being configured with parameters when needed. Hey, why not > simply consider different configuration sources as sources for SAX > events directly ? I don't think we should go that fax to hand configuration over as SAX events. Avalons Configuration object is smart enought for it. Also, I don't like to additionally blow up the sitemap with stuff like ConfigurationSource. I'd rather see that going into cocoon.xconf have a component that is the ConfigurationSource used by Cocoon to hand over the configuration to a CWA. > > >>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. > > > That's what I meant but didn't express. ;) > > >>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. > > > Ok, so the "how" basically has to allow the developer to interchangably > use "soft" and "hard" links all over the place, even though "soft" links > might need one or two steps in addition. > > >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. > > > I would consider this approach an abuse of the XML namespace mechanism, > as in the way it is used in the XML definition, it is setting up a short > namespace alias for the notation ns:element, not as a preprocessing > instruction like #define in C. I think we should be able to come up with > something more clear. > > >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. > > > I am always fearful of prompts that do something for me that I may not > have understood completely. Do we speak of a solely installer-based > approach here or might this allow the admin to just drop-in the .cwa > file and add an entry to the sitemap without anything able to directly > prompt at all ? I see the web based (Cocoon based) configuration editor here for deployment configuration (yes, JMX comes to mind also). Giacomo > > We should give the administrator a way to explicitly name a certain > instance, leaving the administrator the choice between automatic > GUI-driven and good-old vi-driven approaches, as the admin can partially > or completely override the naming scheme and refer CWA dependencies to > their targets manually. Whenever people would use the dynamic naming > scheme to ensure multiple installations do not collide, they show a > certain lack of interest to make sure they connect CWA dependencies > correctly. > > >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. > > > Basically this sounds good ;) > > > > >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. > > > Are there already existing solutions being used in Cocoon ? What about > the cocoon:// protocol ? > > Best regards, > > Michael Hartle > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
