One more thing that I wanted to mention is that for the initial version of Cocoon Blocks, I would suggest that we go simple by following the approach of WARs and EARs. Let's discuss the long term design and vision, however try release an early version, which does not have some of the advanced features like inheritance and dependencies. Being able to deploy naked Cocoon and deploy/undeploy independent components is the one feature that has been requested a lot and we should deliver soon. Offering a good componentizing mechanism is imperative to becoming a respectable top level Apache project.
Ivelin ----- Original Message ----- From: "Ivelin Ivanov" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, November 08, 2002 11:20 PM Subject: Re: [design] Cocoon Blocks 1.2 - Glorified Mount > > Along the way of following this discussion, I came up with the following > suggestion: > > First of all, this is a good page: > http://outerthought.net/wiki/Wiki.jsp?page=UnderstandingCocoonMounts > It is the kind of HOWTO doc we need in the main docs. > > > > > > -====[ Extending <map:mount/> ]====- > > > > > > -============================- > | Part I - the "jar" protocol | > -============================- > > > Let's set the base line with the following popular automount example: > > <map:match pattern="auto/*/**"> > <map:mount uri-prefix="auto/{1}/" > src="http://hostname/cocoon/blocks/auto/{1}"/> > </map:match> > > > > How about allowing the following alternatives for src (partially borrowed > from Tomcat): > > src="jar:file:/absolute/path/to/a/block.cob" > src="jar:http://hostname:port/path/to/a/block.cob"; > > The jar protocol is of course the one handled by the standard JDK net > library. > http://java.sun.com/products/jdk/1.2/docs/api/java/net/JarURLConnection.html > > > Just like JBoss reads EARs from such urls and looks up META-INF/... and > Tomcat reads WARs then looks up WEB-INF/..., we can write in the > specification how Cocoon will read COBs and will look up BLOCK-INF/... (lib, > classes, .xconf, etc.) > > This will possibly allow us to borrow a lot from the J2EE specs in terms of > class loading, security, signatures, deployment, life cycle and other > aspects. > > > > -0-0-0- > > > > -=================================- > | Part II - the "service" protocol | > -=================================- > > > Now, we can also merge the WebServiceProxyGenerator and <map:mount/> into > something like: > > <map:match pattern="auto/*/**"> > <map:mount uri-prefix="auto/{1}/" > src="service:http://hostname/cocoon/blocks/auto/{1}"/> > </map:match> > > > Where the src is prefixed with a service protocol, which implies that > requests which > match pattern="auto/*/**" will be forwarded(proxied) to the URL after > service: and the > output will be available to the parent sitemap, just like with regular > mount. > > This will allow remote hosting of services/blocks, while to the users of the > current applications it will appear like everything is served by it > directly. > To clarify, as far as the service protocol is concerned, it doesn't matter > what runs the remote site. > It can be any web server, including Cocoon. See the following demo for > example of remote service hosted by Amazon and OpenWiki: > http://www.cocoonhive.org/portal/home > > > With this in place we can get rid of the current WebServiceProxyGenerator > and replace it with a simple file generator, which uses the cocoon protocol. > In other words, what used to be: > > > <map:match ... > <map:generate type="wsproxy" src=http://host123/some/service... > > > will become: > > > <map:match > <map:generate src="cocoon:some/service" > > <map:match "some/service" > <map:mount src="service:http://host123/some/service/... > > > > In addition to sitemap simplicity, the offered approach will also allow the > remote call to return any content type, not necessarily XML. Therefore it > would be possible to refer to it from readers and any other component which > uses the Avalon source resolver. > > One more added value is that a site can start simple by using remote > services and then as user demand increases, it will be able to move a Cocoon > block locally by making one simple change, which is replacing the mount src > from service:... to jar:... . > > > One apparent difficulty with the service protocol is propagating all the > sitemap information normally available to locally mounted sitemaps. > I think that this information should be generally unavailable to remote > services. > However explicit parameters could be passed on. For example: > > > <map:match "some/service" > <map:mount src="service:http://host123/some/service/... > <map:parameter name="request-parameter-to-service-1" > value="{local-sitemap-param-A}"/> > <map:parameter name="request-parameter-to-service-2" > value="{local-sitemap-param-B}"/> > </map:mount> > > > > > -0-0-0- > > > > -===[ End of Proposal ]===- > > > > Thoughts? > > > Ivelin > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
