cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Servlet service request
Date Sat, 01 Dec 2007 12:37:04 GMT
Carsten Ziegeler pisze:
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz pisze:
>> Hmmm, I have not considered flowscript when I was formulating my opinion on this
subject and it was
>> an obvious mistake. Your argument is of course valid and it seems that the best compromise
between
>> functionality, performance and separation is to provide access to the data from parent
request but
>> in read-only mode. It means we should allow sub-request to access request attributes
of calling
>> request. When it comes to session (even in read-only mode) I'm very circumspect.
>>
>> I believe that the best strategy is to allow as less as possible that still enable
us to make full
>> use of servlet service capabilities.
>>
>> WDYT?
>>
> I'm not sure - creating an artificial and somehow unusable session for
> sub requests is imho no solution. It somehow doesn't neither make sense
> nor does it feel right.
> 
> In the portal world, the session is shared between portlets and servlets
> residing in the same web application - there is no difference in terms
> of usability between a portlet or a servlet. The portlet spec does not
> want to impose restrictions, however it gives guidance to not mess up
> with the session and missuse it.
> 
> For some applications, the session contains required information like
> the local or some preferences. You definitly don't want to pass them do
> sub requests by getting them from the session and putting them into the
> request.

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

Then profile name 'gkossakowski' becomes a lens that we use to have a view on post 1, stylized
using
red skin and showing controls in Polish language. Lens named 'gkossakowski' can provide additional
settings impacting on how the page looks like. For example, simple "Hello Grzegorz" can be
provided
at the bottom of page.
As you see, URL includes userid that can be used to fetch preferences from database (or webservice,
if we are playing with remote profiles, for example) and use them as a lens. It brings us
straightly
to the conclusion that each resource has zillions of different (but unique and persistent!)
URLs
depending on who looks at it.
Such design results in prons and cons of course. Obvious advantage of having unique URLs for
each
view of particular resource is that you can paste it while having a chat with pal and you
can be
absolutely sure he will see exactly the same page as you see including "Hello Grzegorz" greeting.
The disadvantage is such a weird behaviour that John accesses the page and is welcomed as
Grzegorz.
Simple solution to this problem is to carry information who looks through whose lens. In our
case,
simple cookie with information about real userid could be passed affecting a little a dispayed
page
with information:
"You are looking at this page using Grzegorz settings, if you want yours go here."

Or even you can configure to redirect automatically in such case. It really depends on particular
application needs.

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.

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

> We are relying/basing on the servlet specification and it seems somehow
> wrong to me to explicitly disallow some things just because some of us
> think that this is evil - it doesn't matter if this is evil or not, it's
> the servlet spec in the end. And this spec states that the session is
> shared by all servlets etc. So I think we should give full access to the
> session but explicitly document the problems. If people want to mess up
> with it, well, that's their problem - if people know what they are doing
> and need (write) access to the session, they have it.

Whenever I think about Servlet Services Framework design first spec I have in mind is HTTP
(+
publications about REST that made me think about HTTP in more appropriate way). Always and
ever. The
fact that we follow servlet specification as much as we can instead of reinventing the wheel
is good
of course. Nevertheless, I keep HTTP and REST over servlet spec.

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
and
cleaner contracts. I think that limitations (but well thought through!) are our friends not
evils.

WDYT?

-- 
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message