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

[Chris Croome]

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?

Seen this?

  REST vs. SOAP at Amazon

  Amazon has both SOAP and REST interfaces to their web services,
  and 85% of their usage is of the REST interface. 

  Despite all of the corporate hype over the SOAP stack, this is
  pretty compelling evidence that developers like the simpler REST
  approach. 

  http://www.oreillynet.com/pub/wlg/3005

> >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:

  http://web.archive.org/web/*/http://atomism.demon.co.uk/
 
  http://web.archive.org/web/19961226225706/http://www.atomism.demon.co.uk/

  http://web.archive.org/web/19970409160436/http://www.atomism.demon.co.uk/
  
Were you thinking of using HTTP authentication for usernames?

> 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 a
client, such as googlebot, that doesn't support cookies?

Chris

-- 
Chris Croome                               <chris at webarchitects.co.uk>
web design                             http://www.webarchitects.co.uk/ 
web content management                               http://mkdoc.com/