"William A. Rowe, Jr." wrote:
[snip]
> >
> > Why not? How many protocols will use the state_rec? How many won't?
FTP will use the state_rec for auth info and for the state of for
instance,
the current directory on the server. IMAP and BEEP will use it for auth
info
and maintaining states of the various channels/threads they have.
>
> This is why I'm suggesting that a sub-connection rec _could_ solve the problem for
> stateful models. Just like a sub-request, it's created when needed, ignored when
> it's not. In any case, FTP might not need one, if auth was dropped into the
> identity chain I suggested just a minute ago. A module would grab the most relevent
> connection_rec (last sub-connection added to the chain) in most cases. When the
> part of the stateful session that created the sub-connection finished, it would
> close that sub-connection, leaving the connection flying.
Understanding the conversation regarding the state_rec I believe many
people
think it is only used for authentication information. That is the indeed
a
part what FTP would use out of the state_rec, but it will use more. For
instance,
the state/place where an FTP-user is in the directory tree on the
server.
Take also a look at the IMAP usage example. There is the state_rec used
for
the many states of the individual trheads you can have in IMAP. BEEP
also
would benfit from it since it uses multiple channels (which are in idea
similar to threads in IMAP).
All this is not really achieved by using sub-connections.
Harrie
