Re: [RFC] session_start(), read_only, lazy_write; Take 2

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

« previous php.internals (#73473) next »