> I thought the reporter want valid SID defined always, since I wanted
> valid SID defined always. Document does not memtion when SID is
> defined, IIRC.
>
> Document should be updated.
It has been documented since I first wrote the session
documentation.
"Alternatively, you can use the constant SID which is defined,
if the client did not send the appropriate cookie. SID is
either of the form session_name=session_id or is an empty
string.
> You are forcing "user" save handler to return "" string anyway.
No. Try to read the code again. A user handler should
simply return a non-string.
> 1. It does not work simply with current code.
> (It seems mm works for you. While it does not for me. I guess
> you enable register_globals)
I don't which you can easily derive from the test script I
sent to you earlier.
> 2. There is no way to return fatal error from reading.
> (This could be serious design flaw, since when read failed
> due to lost connection,etc, write function should never try
> to write.)
A php function can itself halt the script execution, so there
is no need to enforce bailing out.
> 1. Since session module functions may not be called sometimes depends
> of its stauts, if function cannot work, it should fail.
This is completely independent of using a bit-vector and is
easily achieved using php_session_status.
> 2. Since original code uses PS(mod) and it's member for current
> status of session module (or save handler), you failed to write
> code correctly. It's much easier and cleaner to use single
> status value to represent session status.
I don't get what you are trying to say there.
> > http://news.php.net/article.php?group=php.cvs&article=9712
> >
> > Does not make sense. Die, if session module cannot be
> > initialized.
>
> Does not make sense web server dies when user set save_path to
> "host=localhost db=session" for their user save handler.
Then the user should either set save_handler to "user" or
not change it all (files is perfectly happy then).
> If we would like to have configurable path, we need new value.
No.
> > I fail to see how this is related to a segfault in the output
> > buffering section as discussed in #14232?
>
> Does not make sense web server dies when user set save_path to
> "host=localhost db=session" for their user save handler.
>
> If we would like to have configurable path, we need new value.
Still no.
> - Use return value to indicate if function worked right or not
Yes, this makes sense at a couple of places.
> - Do not use implicit status using value other than status.
Parse error..
> - Treat session module as simple finite state machine.
> (It a lot easier to maintain)
> - Handle error as soon as possible.
I.e. when the server starts up.
> Most of problems that I've found is related to these.
>
> BTW, you are better not to say other's patches are bogus.
> We know there are sevral serious bugs. One can easily argue
> that your code or coding style is bogus.
> But, it's not productive at all ;)
It is apparent from your patches and comments so far that you
lack a deeper understanding of parts of the session module
and its design. This might be related to the sparse
documentation, but that does not excuse you from deliberately
committing patches which had been rejected multiple times by
the maintainer. This is simply considered bad form.
I would encourage you to dig deeper into the code to further
your understanding of how the systems interact. If you have
any questions, please feel free to ask the author of the
specific code.
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
