On 29 Jan 2014, at 11:17 PM, Erik Pearson <e...@adaptations.com> wrote:
> Actually, the more I've delved and actually used mod_session and friends, the > more fundamental the changes have become. For instance, a lot of the code > that lives in mod_session_cookie and mod_session_dbd seems more appropriate > for mod_cookie -- including session name, session caching, session object > creation. With such changes, it is quite difficult to isolate into single > issue diffs. I'm not following the problem you're trying to solve. It seems you're trying to rearrange and group technologies together from a programmer's perspective, instead of grouping functionality together from an end user's perspective. Right now, if an end user wants to store a session in a datastore of some kind, in the classic "application server" model, storing a reference to that session in a cookie, they enable mod_session_dbd. If instead the end user wants to store the whole session in the body of a cookie on the client, they enable mod_session_cookie. In future, should the end user want to store a session in memory, they might use a future mod_session_socache. What you seem to want to do is combine mod_session_cookie and mod_session_dbd, simply because a cookie is involved in both. That doesn't make life easier for end users, who are only interested in getting a job done. Regards, Graham --
