cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Servlet service request
Date Sat, 01 Dec 2007 22:47:44 GMT
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
> /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.

> Ok, you may think it's academic speaking (yes, I'm a student spending most of my time
at very high
> levels of abstraction) but I really believe it may work and scale very, very well. It
goes in
> harmony with REST principles, and... there is no session needed. All user preferences
all in
> persisted all the time.
Yes, it's possible to build applications following these principles -
but it's also impossible to build all applications going this road.

> Getting back to the topic, I tried above to proof that having a session is not essential
part of web
> application creation process.
Again, in the general case, it is.

> I think it's worth to remind KISS rule as it fits very well in this case. If we let a
session to be
> shared at this point there will be probably no way back. Apart from SSF being a really
nice idea, I
> like to work on it becuase, in contrary to cocoon protocol, it allows much less thus
code is
> simpler, cleaner. Also, it makes me to think more about a proper design of my applications
that will
> fit into narrowed functionality. The overall result is always a better SoC, better design
> cleaner contracts. I think that limitations (but well thought through!) are our friends
not evils.
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.

Carsten Ziegeler

View raw message