Re: [RFC] session_start(), read_only, lazy_write; Take 2
| From: | Yasuo Ohgaki | Date: | Fri, 28 Mar 2014 22:02:46 +0000 |
| Subject: | Re: [RFC] session_start(), read_only, lazy_write; Take 2 | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-73473@lists.php.net to get a copy of this message | ||
Hi Andrey,
On Fri, Mar 28, 2014 at 7:50 PM, Andrey Andreev <narf@devilix.net> wrote:
> >> I still don't get it ... the session manager has to call either
> >> write() or updateTimestamp() and both of these are part of the session
> >> handler. Merging them into one solves the API design and BC issues, I
> >> don't see how it breaks any principle. They can still be split to two
> >> methods in PHP6, but for the time being, using write() for both
> >> purposes IMO solves way more problems than sticking to this design
> >> principle you're talking about.
> >
> >
> > Without API, manager cannot manage how it behaves. In general, submodule
> > should
> > avoid manager state dependency in general. It should have dedicated API
> for
> > each
> > distinct task rather than leaving it to managed by submodule. In
> addition,
> > manager
> > cannot know if save handler supports API or not. If there is API, I can
> > display save
> > handler capability in phpinfo() page, for example.
> >
> > If manager expects sub module to behave in some way, it should have
> explicit
> > API
> > for each feature. Otherwise, sub module implementation may differ module
> by
> > module.
> > Defined set of feature is better to have explicit API with modular
> design.
> > It's not mandatory,
> > but the best practice. I don't see reason not to follow the practice
> here.
>
> I agree in general, but you just gave a good reason not to follow that
> practice - you can't know if the submodule supports it. Plus, both are
> write operations with one of them just writing more data. I'm all for
> best practices, but in this case there's a lot of sense not to do
> everything by the book.
>
If there is API, sub module capability can be detected.
Writing data and updating time stamp for GC is distinct feature.
I don't see good reason not to have API for it.
>
> > Besides modular design, if write() and updateTimestamp() are merged, flag
> > parameter
> > for write() should be added. It breaks compatibility with current save
> > handlers. I don't
> > want BC that could be avoided also.
>
> No it shouldn't, the decision whether to write or just update the
> timestamp is based on an internal flag, or on $session_data. No
> additional parameters are required.
I removed PS(id) dependency from s_read() with new patch as planned. Why
should I introduce new dependency to s_write(), i.e. sub module, that
breaks
design? It does not make sense.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net