[ruby-talk:8602] Re: Problem - CGI::Session (long)

Yukihiro Matsumoto wrote:
> 
> 
> the behavior of new_session is:
> 
>   true          | should start new session; session id must not be
>                 | provided.
>   --------------|------------------------------------------------------
>   false         | should continue existing session; requires session
>                 | id to be provided/created.
>   --------------|------------------------------------------------------
>   not supplied  | start new session, or continue existing session,
>                 | depending upon the context
>
> So if you DO NOT supply new_session at all, I think you have what you
> want.
> 

Thanks for answering, matz.  But why was it done this way?  

Here is my experience of how the table works:
 
   true          | creates new session unless session id is provided
                 | in options hash; ignores session id from cgi requests 
   --------------|------------------------------------------------------
   false         | never creates new session; if session id is not provided
                 | nor found in cgi requests, then exception is raised
   --------------|------------------------------------------------------
   not supplied  | continue existing session, or create a new one if no
                 | existing session is provided nor found in cgi requests


It is hard to follow this, maybe. But for me at least, it is easy enough to 
tell that the most useful/common behavior is 'not supplied'.
 
What cgi programmer is not going to need a session to be created 
when an existing one isn't found?  

In fact, shouldn't 'false' actually have the effect that 'not supplied' has?
(In any case, I think the use of true/false for new_session is debatable).

The whole thing strikes me as inconsistent, yet very fixable.
But I have seen no one else agree with me - am I the only one using this?

I suppose I could always write my own sessions module (and I am on the verge
of doing so for my applications), but I'd rather first cooperate. :-)
I could also bypass cgi/session's lookup algorithm altogether and do my own
lookup or creation logic and provide initialize() with the session_id everytime.
But I really think all cgi programmers are going to need to do what I am
doing, so why not make it easier for us? Or is there a large number of people
who actually do not do things this way.

(btw matz, in your table, you write that 'false' requires session id to be 
provided/created. But it can't be created since new_session=false.)

> |But I cannot guarantee that the new_session key will or will not be
> |an entry in the options hash, and I would certainly like to
> |guarantee a new session in case I can't recover an existing one.
> 
> I don't know the reason why you cannot garantee.  Why don't you simply
> remove 'new_session' from the option hash in that case?
>

That is a good temporary fix - thank you.  But don't you think it is an
unusual way to do something - by ensuring a key is *not* in a hash?

Why not make =false behave the same as if it were not supplied?

Besides, even cgi/session assumes there is always a session - did
you notice that it has a default value for the session_key? 

Is there a reason why setting new_session=false is not the same
as the new_session key being 'not supplied'?

Thanks.


Guy N. Hurst


-- 
HurstLinks Web Development    http://www.hurstlinks.com/
Norfolk, VA  23510            [phone] FAX [phone]
PHP/MySQL - Ruby/Perl - HTML/Javascript