Re: [Mod-c-users] Session structure

[Gonzalo A. <gon...@gm...>]

On 8/25/06, Matej Urbas <mat...@gm...> wrote:
> On Fri, 2006-08-25 at 10:07 -0300, Gonzalo Arana wrote:
> > > Well, I've seen ASP.NET having a directive that lets the user decide
> > > what size of Id one can use.
> >
> > I find quite difficult to imagine a good session ID generation
> > algorithm for abritrary session length.  I would rather loose this
> > feature but require to have a good sessionID generation. (what I
> > demand for a 'good' algorigthm: below).
>
> Ok, so here is what we can do:
>
> Id structure (taken from your mail):
> |<-- timestamp -->|<-- geostamp -->|<-- variable sized random bytes -->|
>       4 bytes          4 bytes                   8 >= bytes
>
> (I like 8 more :-P)
>
>  - timestamp and geostamp will not make the Id unique

nice, perhaps we could add process id and a sequential uint32_t.  This
way we are even closer to be unique.

> I have devised a random byte sequence generator in mod_c_dss. I guess it
> is secure enough.
>
> And I guess we'll have to create an Id generation daemon for (guess
> what) Id generation :)

I agree.  Although I would like to make each ethml instance to
generate its own unique session id, perhaps the best approach would be
to have a server for this matter.

Perhaps we can include a disk-based session store (ala php).  This
would make things easier (avoid writing a daemon).

> > > > 2) Session id generation is in session backend, so if we want to use a
> > > > different store (say, *sql, dbm, etc) we have to write a session id
> > > > generation algorithm for each one of them.
> > >
> > > Aye. Would be stupid do reimplement the wheel over and over again.
> >
> > Indeed :(
>
> So the plan is to redesign the session API?

yes, I was thinking in redesign it.  Later I'll send a document
explaining a possible approach.

> We'll have to retain the plug-in system - to be able to load and select
> session types dynamically for each directory.

I agree.

> The API must be well defined (I know mine was pretty ad-hoc) and should
> support:
>
>  - persistent connections
>  - starting a session
>  - recalling an active session
>  - ending a session
>  - storing/retrieving binary data only (takes a load off of driver
> developers - a wrapper should be responsible for more user-friendly
> storage strategies)
>  - it should provide some standard info about the current session: when
> it was created, how many bytes are stored etc...
>  - perhaps data caching (BeginTransaction - FlushTransaction) to send
> data in one go.
>
> You name it...

That is all of what I was thinking of.

> Well, my idea is to keep the session API as simple as possible, but it
> should provide enough to create a wrapper on top of it. We will provide
> a wrapper for session storage in EHTML and everyone will be happy :-)

I keep agreeing.

> Well, you should tell me :P
>
>
> > > Well, yeah. They would use the session API to achieve this, no? Wrap
> > > around it... EHTML could provide such key-value session storage. To make
> > > it easier to use. Let say EHTMLApplication will have a
> > > Session.SetValue(key, value) and Session.GetValue(key). I think I have
> > > done something in this way already - but I forgot.
> >
> > I agree, this would imply marshalling/serializing support in Session class.
> > That's something I am definetely in favor of.
>
> Yep, it is a must in EHTML at least. Of course one is not obliged to use
> EHTML and could use the session API directly or with other wrappers -
> not bound to EHTML.
>
> But since EHTML is a convenience library, it should also integrate
> session storage...

Amen.

> >
> > That's a good idea, but by 'keyed data' I was meaning 'keyed by session id'.
>
> Isn't this actually what's being done right now? Storing keyed data?

Yes, but I would like to split session handling in:
1) session storage,
2) session id generation
3) session data serializing/marshalling.

I guess 1 & 2 need plug-in structure, while 3 does not.

So the responsability of session store is *only* to store keyed data,
not 2) nor 3).

> > > > 3) Shifting your current UNIX-socket-based default session handler to
> > > > TCP should be quite trivial.  I would do that as well.  This way, we
> > > > can have a single session server among a cluster of apaches.
> > >
> > > Yes it is trivial, I planned to do it at some later stage, but I never
> > > got to it :P
> >
> > :D I'll do it, relax.
>
> Nice :-) There is a comment in the default server's source file - it
> says:
>
>     // TODO: Add the remote part of the server...
>
> You should mainly copy everything that is just above this comment and
> use normal sockets instead.
>
>
> Things look promising to me ;-)

Same to me.

Later on I'll submit a document summarizing all of this.

Regards,

-- 
Gonzalo A. Arana