Re: Zend_Session, Zend_Session_Core, and Zend_Session_Namespace?

Gavin,

This is a good overall solution.  I realize now that part of my problem with 
Zend_Session_Core was that it was not so much a wrapper for ext/session but 
a catch-all class for everything not dealing with namespacing.  The API and 
class names seems more logical now.  At this point we're just ironing out 
the details.
Having said that, I have time now and I might not later, so I'm going to go 
ahead and throw out implementation comments as well:
1. Should Zend_Session_Namespace extend Zend_Session_Persistence?  It seems 
like Zend_Session should extend Zend_Session_Persistence, but should 
Zend_Session_Namespace extend it as well?  I realize that this is to avoid 
repetition, but perhaps instead the functionality of the static namespace 
methods should be moved directly into Zend_Session_Namespace and it can 
either extend Zend_Session or (better yet, to avoid the possibility of mixed 
API) have some property referencing the session-handling class 
('Zend_Session').  Then, in the unlikely event that someone wants to extend 
Zend_Session or use their own session handling class, they just have to 
extend Zend_Session_Namespace and change that property to their new session 
handler.
2. Is it possible to offload persistence methods from Zend_Session into 
Zend_Session_Persistence, with convenience methods remaining in 
Zend_Session?  Then Zend_Session_Persistence can have something to do, and 
its purpose reflects its name a bit better.
If Zend_Session_Namespace no longer extends Zend_Session_Persistence, 
abstract methods intended for Zend_Session can be declared without a problem 
if they're ever needed.  For example, if the cookie methods are moved into 
Zend_Session_Persistence, then regenerateId() will need to be declared 
abstract.  The rules of what constitutes persistence need to be defined 
(e.g., do cookies count?), and methods falling into that should be moved.
3. Can the constructor of Zend_Session now become private?  It doesn't 
really follow the Singleton pattern anymore since there's no instance.
4. There are still some references to "core" in some of the classes.  Those 
probably need to be updated.
Thanks,

-Matt

----- Original Message ----- 
From: "Gavin Vess" <gavin-C1q0ot2/XZ0@xxxxxxxxxxxxxxxx>
To: "Zend FW Auth List" <fw-auth-wwOhfgvld6hpLGFMi4vTTA@xxxxxxxxxxxxxxxx>
Sent: Tuesday, January 30, 2007 9:44 AM
Subject: Re: [fw-auth] Zend_Session, Zend_Session_Core, and 
Zend_Session_Namespace?
> Many of you have made reasonable and justifiable statements about the 
> features currently supported by the Zend_Session* classes, and the 
> implementation.  The dependency injection feature has the lowest 
> importance, and was merely a "nice to have" feature that was mostly 
> interesting to whitebox testing.
> We have a new branched version of Zend_Session* in SVN. By dropping that 
> feature, then fully separating ext/session "management" related functions 
> into one class (Zend_Session), and isolating the session namespace 
> container functions to another class (Zend_Session_Namespace), I believe 
> we have addressed most concerns voiced recently.  A third class was 
> created as a common, shared superclass to share some code and avoid 
> duplication between the other two classes.
> If PHP fully supported defining an "API" from a list of methods, and then 
> explicitly exporting and importing specific APIs to/from other components, 
> then I would have done things differently.  The combination of supporting 
> dependency injection, and the lack of support for exporting/importing APIs 
> resulted in some incongruities in the original Zend_Session, as noted by 
> Willie.
> The new experimental code resolves these, does *not* add new features, and 
> it is about 97% backwards compatible.  The new code may be reviewed at:
> svn co http://framework.zend.com/svn/framework/branch/session-pre0.8
> http://framework.zend.com/fisheye/browse/Zend_Framework/branch/session-pre0.8
>
> I ask that we first focus primarily on the public API of the ext/session 
> "manager" (Zend_Session), and the session container namespace 
> (Zend_Session_Namespace), before worrying too much about implementation 
> details.  For example, do we have names for these classes that are 
> intuitive to PHP developers with average experience?  Please see the 
> examples at the end of this email
> Cheers,
> Gavin