Hi!
> Well, as I said: I don't think the previous RFC was handled properly.
> This is probably because it isn't detailed enough for people to
> understand it (I for example wouldn't vote for, or against something
Are there any other people that you know that think so? Because it makes
a precedent for never ending RFCing - somebody creates RFC and holds a
vote, you don't like the result so you create counter-RFC, then they
create counter-counter-RFC and in the meantime nothing gets done. There
should be a point where the decision is taken. That doesn't mean we
can't reconsider, but not a minute after the vote ends.
> Yes, on a basic level the currently accepted 'read_only' matches your
> explanation. But there's more to it than that ... options should be
> viewed as modes of operation (IMO anyway), and currently this is an
> "option" that actually performs an action, and that's not even
> obvious. 'read_only' just doesn't have the same meaning as
> 'read_and_close', which because is an action, should be a separate
> function.
I'm not sure I understand your complaint. We already had the
session_abort function, and nothing prevents you from using it if that's
what you want. What you couldn't previously do is to quickly say "I'm
not going to change state" and be done with it. It is a real use case
and the RFC enables it. We already have all the components
(session_abort), we just enable doing it in a clear and explicit manner
that allows people reading the code know what's going on.
> As for the login check example, maybe it isn't clear enough. What it
> demonstrates is a decision making process, you don't know what happens
> afterwards. What if, for example, Request2 deletes a row from a
> database at the time of logout and Request1 tries to read the same row
> (knowing that it is there because the user is logged in)? The
> application breaks.
Right, you can write app with broken logic (like assuming the DB row is
there because of something that is not related to the DB row and can be
changed independently). I don't see how this relates to read_only - you
always could and always will be able to write apps with broken logic.
> How useful that would be is not the point, currently. The problem is
> that this is exactly what 'read_only' should mean as an option/mode.
> If that name is taken, how would you call it in the future?
I don't see any reason why this option "should mean" what you claim it
should mean. That's just your misunderstanding of what it does, easily
rectified by a quick look into the docs.
> I didn't mean incomplete in the sense of "it works, but can be
> better", but rather as "it only works in half" or "we don't know how
> it works in some cases". The RFC itself is incomplete, it doesn't
Where we do not know how it works? The feature is very simple - when
session data is about to be written, we compare it to the session data
that has been read, and if they are identical, we do not issue write.
Not many cases here as far as I can see.
> "last used", "last updated", "last modified", "last
> accessed" ...
> however you call it, it always exists in some form. Without such a
Last used and last modified are very different things. Nothing prevents
one from tracking either. We need to check it is done properly and is
compatible with old handlers, but it should be entirely possible to do
it in a BC way.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227