httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harrie Hazewinkel <har...@covalent.net>
Subject Re: Apache 2.0 for multi protocol usage
Date Tue, 10 Apr 2001 08:33:11 GMT
Greg Stein wrote:
> 
> 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.

It is not only the user info we are talking here in case of FTP.
It is also that in FTP you have to maintain information on
where the current user is in the directory tree, since the next
request this user will do acts upon or relative to this directory.
And how do you want to do the states of the multiple threads with IMAP??
You are here taking 1 minor piece that needs to be done by the 'state'
layer.

> 
> 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.

Yes, it will be a bit more complex, but the support of many
protocols becomes easier. If you want to do more of course
it becomes more complex.

> 
> 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.

If so, then saying Apache 2.0 is a multiprotocol platform is not true.
It start to get ready for it, but just starts and nothing more.
Yes, I understand that mod_echo is a protocol (it has indeed its own
RFC),
but it is a very minimalistic protocol.
And from more complex protocol module you are going to ask to do for
every protocol the same things internally. The idea behind this is
simple
to avoid re-inventing the wheel for every protocol you want to
implement.

I have heard people speaking of using Apache to implement SAMBA. Are
those
guys also on this list?? They probably also have some real coding
experience
in this area.

> 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.

I understand you don't like the idea that it will break Apache serving
pages.
But splitting it up in many minor patches over time is even more
difficult.
Adding an extra layer is almost an atomic step. It is there or it is not
there.
You cannot do it halfway.


Harrie


Mime
View raw message