cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: [design] Cocoon Blocks 1.2 -> Iterative development is good
Date Sat, 09 Nov 2002 05:33:59 GMT

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" <ivelin@apache.org>
To: <cocoon-dev@xml.apache.org>
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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message