Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <47522278.80601@dslextreme.com>
Date: Sat, 01 Dec 2007 19:11:52 -0800
From: Ralph Goers <Ralph.Goers@dslextreme.com>
Reply-To: rgoers@apache.org
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Servlet service request
References: <20071129220613.180721A9832@eris.apache.org>
 <474F3A70.6070001@apache.org> <474F4D69.7070704@apache.org>
 <474FBE76.60407@apache.org> <474FC59D.1050201@apache.org>
 <474FD147.3000900@apache.org> <4750860A.9000208@apache.org>
 <475097CB.7050909@apache.org> <47515570.3040809@apache.org>
 <4751E490.4010200@apache.org>
In-Reply-To: <4751E490.4010200@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler wrote:
> Grzegorz Kossakowski wrote:
>   
>> It may sound controversial but I think that things like information about user locale or preferences
>> should be kept in URL (preferably in path part or in request parameters). If data set is too big,
>> URL should contain an unique identifier of this data set. I mean, instead of using following URL:
>> /blog/posts/1
>> and passing following information: Locale=pl-PL, Username=gkossakowski, Skin=red
>> it's better to have following URL:
>> /blog/languages/pl-PL/skins/red/posts/1
>>
>> Or, if username is needed for other reasons (like we need to access other preferences):
>> /blog/profiles/gkossakowski/languages/pl-PL/skins/red/posts/1
>>
>>     
> Yes, following the REST principle is a good way to build web
> applications (and their URLs) - but that's not always possible/desired.
> There is information you definitly don't want to put into the URL for
> security reasons (Ralph outlined some of them) - and a URL has a maximum
> length - and sooner or later you'll hit this limitation if you want to
> put everything into the URL.
>   
I suppose REST is fine for some trivial applications on the web tier, 
but many modern web frameworks (i.e. JSF, Spring Webflow, Wicket) 
require that state be maintained on the server simply because they have 
a requirement that pages be accessed in specific orders. I believe even 
flowscript and Javaflow require this to preserve the continuations.  
REST between the web tier and the business tier is a different matter. 
The business tier should always be stateless and REST (as a concept) 
works very, very well for that. However, when you start talking REST vs 
SOA vs RPC the lines can get very blurry. I would contend that it is 
possible to actually implement something in the business tier that is 
actually all three.
> I think Ralph put it very nicely:
>   
>> I think the answer is simple. The session needs to be shared with all
>> servlets in a webapp just as the servlet spec provides. Anything less
>> is going to confuse the heck out of users, lead to nothing but trouble
>> in the long run and give the impression that Cocoon just tries to make
>> everything hard on purpose.
>>     
>
> If we don't provide the real session, we violate the servlet spec (ok,
> of course not directly as the servlets are not registered in web.xml).
> And this leads to too much problems in the long run. It definitly will.
> By giving example that don't use a session, people will lern to avoid
> the session whereever possible, but again, there are valid use cases for
> sessions. And I think we shouldn't stop them from using Cocoon.
>
> If you want to be sure for your own applications, that no session is
> generated/used, you can either use some aop magic and throw an exception
> whenever a session is accessed - or you can write a simple servlet
> filter doing the same.
>
> And as Ralph hinted as well, the Portal needs a session (well, not in
> all use cases but that's a different story). And the portal currently
> uses the cocoon protocol which will be replaced with the servlet
> protocol. And the sub requests called by the portal need access to the
> session as well.
>
>   
I suspected that you might make that switch, although I'm not really 
sure what the benefits are. Will it allow coplets to be individual 
blocks with the portal being a separate block? If so, that would be 
great.  In that case it might be possible to make JSR 286 portlets be 
blocks as well (in addition to the requirement that they be separate war 
files).

Ralph