Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (nike.apache.org: domain of grek@tuffmail.com designates
 216.86.168.178 as permitted sender)
Message-ID: <47744F52.1010205@tuffmail.com>
Date: Fri, 28 Dec 2007 02:20:18 +0100
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20070801)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support
 absolute
 URIs
References: <11551087.1198667503258.JavaMail.jira@brutus>
 <4772380E.7020107@tuffmail.com> <4772991D.2040102@apache.org>
 <4772C133.9090906@tuffmail.com>
 <769016D0-CEAA-474E-A4D0-7744E2694DA4@reverycodes.com>
 <4774103C.80205@apache.org> <47744240.2010003@gmx.de>
In-Reply-To: <47744240.2010003@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Joerg Heinicke pisze:
> 
> Could anybody please sum up what the actual problem is and what the
> proposals are to solve it? So far I only got that there is an issue with
> cache key which can be solved by absolutizing URIs. Now there is this
> relative vs. absolute URI thing. What for do we need the +? What's the
> scheme for relative URIs?

Yeah, sure. Little bit background on caching issue:

Currently ServletSource.getURI() method returns relative URIs that look like this:

    servlet:[connection_name:]/path

Where connect_name is name of connection to another servlet that is defined locally in a given
servlet. If it's omitted then it means that URI references to the current servlet. The conclusion is
that URIs of that form are relative to the servlet they are resolved in. E.g. servlet A can connect
to servlet C with connection name "foo", and servlet B can connect to servlet D with connection name
"foo" as well. Then in servlet A URI:

    servlet:foo:/path

point to completely different resource than the same URI in servlet B. We came to conclusion that
the best way to absolutize URIs is to replace connection name (that is local to the given servlet)
with servlet ID (more precisely, Spring bean ID) that is unique in whole application. Then if we
absolutize URI from example above being in servlet A it would look like:

    servlet:servlet_C:/path

and in servlet B the same URI would look like:

    servlet:servlet_D:/path

The only problem is that we have no way to check if given URI contains connection name or servlet
ID. Therefore the idea to add special sign that would remove the ambiguousness appeared. Current
proposal are:
a) add a plus sign after servlet ID (by Reinhard)
b) add a exclamation mark at the very beginning of the path (by Vadim)

My personal preference is a plus sign but as Reinhard already pointed out it does not matter that
much because we usually won't be using absolute URIs directly.

                                                 -- o0o --

Now it's the time to give some description of static connection list problem. Currently one can
define list of connection of a given servlet statically in XML config. If you compile a block there
is no chance to add new connections to other servlets. Now, imagine situation that you have some
application making charts and you create separate block (and servlet) for each datasource provider.
For example, you create block that extracts some data from database and second one that extracts
some data from mailbox. If you want to pull this data, you need to connect to these two blocks of
course so you add them to your local connection list.
Now you can compile your application and everything will be working fine. But what if you want to
define another datasource for your charts, for example data from some web service? Of course you
develop a new block that downloads and transforms interesting data but you need a way to inform your
appliction that there is a third block. The most obvious way is to add connection to the third block
but this involves recompilation of your application!

The solution that I and Reinhard (and probably others) have in mind is to let servlet use absolute
URIs so you don't need to define connections statically to other block. There would be also some
discovery mechanism of available blocks, probably a generator, that would return you a list of
blocks fulfilling particular needs. The list would contain servlet ID of each servlet (block) so you
could reference them later on.

I hope this helps you a little bit.

-- 
Grzegorz Kossakowski