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]
