On Mon, Apr 09, 2001 at 03:15:31PM +0200, Harrie Hazewinkel wrote:
> Greg Stein wrote:
> > And punt that darn state_rec thing.
>
> If it is the name, no problem we can discuss that.
> In various discussions the name suggested was
> session_rec. This was th original name RyanB and I had.
> However, some found the name confusing with
> the sessions as being used in HTTP which are for instance
> cookies. That was considered a session so we used here state.
>
> With respect to eliminating the state_rec as layer, I
> am wondering how you otherwise will transer data
> between requests and maintain state. The pool-lifetime
> is the problem. IMHO, it also maps more cleanly towards
> the protocols.
Okay, let's consider FTP. In that protocol, you have a "current user"
associated with the FTP connection. That user remains until it is explicitly
switched to somebody else. I see that as associated with the connection, so
I'd expect an auth_rec hanging off of the conn_rec. When it gets changed,
then you put a different value into the auth_rec.
I don't see adding another layer. That throws complexity into the mix when
we least need it. If we're going to be revamping the connection/request
stuff in a big way, then we want to avoid as much as possible.
For a future version, after the basic changes are done, if we find that a
new layer makes sense (as a "session" or whatever), then we can add it. But
it is too much to ask for right now.
I'm already leery of these changes, especially after seeing klomp not return
data reliably. I'd like to see the changes done in bits and over time. No
monster patches.
[ note: I think the monster patch there could be much smaller if a couple
things are done separately: *if* we keep the state layer, then keep
r->connection for now (so you don't have to change everything to
r->state->connection); do the ap_get_request_user() patch separately (this
could be done today with no harm; although I did see one
"ap_get_request_user(...) = ..." which is seriously bogus; add an
ap_set_request_user() function/macro) ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
