cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [jira] Created: (COCOON-2154) Servlet:/ protocol: Support absolute URIs
Date Fri, 28 Dec 2007 09:55:40 GMT
Ralph Goers wrote:
> Thanks for the explanation, except I'm still not clear what a 
> "connection name" is. See below for my 2 cents.
> 
> Grzegorz Kossakowski wrote:
>> 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.
>>   
> Yuck, yuck, yuck.  (If you get the impression I don't like a or b you 
> are on track).
> 
> c) Use a different scheme to identify one vs the other.

In my perception this is strange too because it's more or less the same.

> d) Use a different pattern. i.e "conventional" urls look like 
> http://authority/path where authority can be a variety of things such as 
> "server[:port]", "user@server[:port]" and server can be a domain name or 
> an ip address. In this case, you could do something like 
> servlet://connection@local/path which, if I understood you correctly. 
> could be abbreviated to servlet://connection/path. For servlet id you 
> could use the same syntax with servlet://connection@servlet_id/path. Of 
> course, since I don't really know what a connection is I have no idea if 
> this makes sense, but it could certainly be abbreviated to 
> servlet://@servlet_id/path.  Or use servlet://[connection][:id]/path, 
> although servlet://:Servlet_C/path still looks a little odd.

This doesn't solve the problem that we have to distinguish between a connection 
name and a servlet name.

The servlet-service framework is based around the concept of servlets. In the 
current implementation each servlet is configured using Spring as a bean. In 
difference to the original servlet concept, servlet-service-fw servlets can have 
connections to other servlets. This way inheritance and composition are implemented.

Now there are two situations: If you are in the context of a servlet and want to 
use another servlet which is configured as connection, you can call it by this URI:

servlet:[connection-id]:[path]

e.g. servlet:some-connection:/foo/bar

However, there are also use cases that don't allow you to define all relations 
to other servlets beforehand because you don't know them at the time of 
development. If then there is a need for a servlet URI, you need to access that 
servlet directly  via its bean name:

servlet:[bean-name]:[path]

And that's the problem: Comparing both URIs you can't make a difference between 
the relative and the absolute one. From here we've started our discussion about 
+, ! and other signs.

> + and : characters in uri's just plain look strange, even if they are 
> allowed, unless they are used in a similar fashion to existing schemes. 
> Also, not having the // in the uri makes one wonder just what the token 
> before the first slash is. Everybody knows that whatever follows the 
> double slashes is not part of the path so it is less confusing.

Does anybody have a pointer to the discussion why double slashes are wrong in 
our situation? (I remember some mail by Pier that explains why the double slash 
in the Cocoon protocol is wrong but can't find it.)


>>                                                  -- 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.
>>   
> I still don't quite get this connection thing.
> 
> What I don't get is why this can't just be servlet://service@block/path? 

We would misuse the authority part of a URI for the purpose of defining the 
service name.

> Or better yet, why shouldn't my application just reference a bean id and 
> wire it to the block service in its Spring configuration (think Spring 
> remoting)?

See above. In some cases you don't know all the references beforehand. It's 
similar to the use cases for the bean map (Spring Configurator).

-- 
Reinhard Pötz                            Managing Director, {Indoqa} GmbH
                           http://www.indoqa.com/en/people/reinhard.poetz/

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair        reinhard@apache.org
_________________________________________________________________________

Mime
View raw message