Sessions and Users, was: Re: [Pangloss] [RFC] OpenFrame AppKit ideas

[Steve Purkis]

On Tuesday, April 8, 2003, at 05:39  pm, Chris Croome wrote:

> Hi
>
> On Tue 08-Apr-2003 at 04:16:49PM +0100, Steve Purkis wrote:
>>
>> On Tuesday, April 8, 2003, at 10:01  am, Chris Croome wrote:
>>
>>> GET should never change state on the server side, that should be
>>
>> I'm not sure I want to worry about being REST-compliant...  At any
>> rate, it wasn't something I was factoring into the design.
>
> If it's thought of from the beginning I'm not sure it's any more
> work?

I dunno - the only thing I remember about REST is not mixing up GETs 
and POSTs :).  If its easy to do for Pangloss then I will do.  I would 
prefer to keep the underlying architecture more generic.


>>> But perhaps I'm missing something -- what is the idea behind
>>> sessions?
>>
>> The idea in general is to have somewhere to store information
>> about the current user, their request, etc. without having to
>> worry about passing a whole bunch of form parameters back and
>> forth.  How it is used is up to the application developer.
>
> Form parameters are not the only why to make these things available
> in a URI, you can use PATH_INFO, a funny example:

I could use PATH_INFO, yes.  But if I did, I would still plan on using 
sessions.


> Were you thinking of using HTTP authentication for usernames?

We have to in order to be compatible with MKDoc users.  Though that 
will only be for user names - I imagine Pangloss will have different 
user objects under the hood.


>> From Pangloss' point of view, consider the multi-faceted
>> navigation.  I was thinking of storing the user's "filters" in the
>> session -- so when you choose to filter based on a translator's
>> name, that information goes into the session.  Same goes for the
>> language, search keywords, etc.  In this fashion, you don't need
>> to have hidden form fields for each filter you've already
>> selected, which means less work from the template writer's side of
>> things, and also means the application doesn't need to repeat the
>> same work (constructing the filters) for each request.
>
> So you are suggesting the use of cookies? How would this work for ...

Not necessarily - the session id can be stored a URI, cookie, or form 
parameter.


-Steve