You are viewing a plain text version of this content. The canonical link for it is here.
Posted to rivet-dev@tcl.apache.org by Tom Krehbiel <to...@motorola.com> on 2004/02/18 18:07:36 UTC
Session Quesions/Comments
The following question was posed as part of my comments on the documentation,
but I wanted to expand on it a little since the session handling is apparently
new. As background to what follows, my experience is limited to session handling
in PHP and doing myself a long time ago.
From a previous email--
I didn't understand the discussion of the session database interface. I'm
familiar with RDMS systems but the discussion concerning table generation
appears to be Postgres specific. I worked with Postgres a little a long time ago
but don't remember enough to be sure. Examples using SQL would be better at this
point in my opinion. I also don't understand your reference to DIO. I checked
google and didn't get anything useful and the MySQL web site same result. Is DIO
some type of API definition like ODBC?
New--
In PHP the default session handling store is done in a file(s) on the server. It
seems to me this would be a good starting point for a session system in Rivet
and would allow new users (such as myself) to evaluate Rivet without requiring
the initial installation of PostgresSQL. Storage and recall of keyword-value
pairs for the session using array get and put should be trivial unless there is
something I'm missing.
Tom Krehbiel
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by "David N. Welton" <da...@dedasys.com>.
Karl Lehenbauer <ka...@sc.com> writes:
> Hmm, well Rivet's session code does not lean heavily on SQL
> capabilities. It could easily support sessions using flat files. I
> will look into adding a switch and supporting both, this weekend.
Excellent. I think that would make it a lot easier for people to
"just get going" without doing a lot of setup.
> We have a login system that sits on top of the session stuff. We
> want to clean that up and release it, too.
Cool!
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Karl Lehenbauer <ka...@sc.com>.
Hmm, well Rivet's session code does not lean heavily on SQL
capabilities. It could easily support sessions using flat files. I
will look into adding a switch and supporting both, this weekend.
We have a login system that sits on top of the session stuff. We want
to clean that up and release it, too.
Karl
On Feb 25, 2004, at 10:00 AM, Tom Krehbiel wrote:
> David,
>
> <snip>
>> Hrm, Metakit is one possibility, but I don't think it does locking,
>
> Good point, I didn't think it through. With multiple instances of
> rivet running locking would be a problem. Putting a file per session
> in a session subdirectory on the server should still be ok for a quick
> and dirty session store.
>
>> which is really pretty important. I think SQLite is maybe a bit
>> better for our purposes.
> <snip>
>
>
> FYI: I found out that postgreSQL exists on one of our subnets (in
> another state). Right now I'm trying to determine if any of the header
> files still exist.
>
> Tom K.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Tom Krehbiel <to...@motorola.com>.
Karl,
Great!! This is exactly what I was thinking. Using files should be a good way
for a newbie to try out rivet.
Tom K.
> Locking should not actually be necessary as long as the session IDs are
> unique, as the filenames will be based on the session IDs. And they
> oughta be unique because they're based on an md5 hash of a bunch of
> different, changing stuff.
>
> Cleanup is handled the same way it is handled in php's sessions. A
> certain percentage of the calls to get a session ID (by default, 1%)
> result in a cleanup. With SQL the cleanup is a delete from table where
> session age > a day. For file-based sessions, it's the same deal, only
> it's done by driving through all the files and deleting ones whose
> modify time is greater than a certain amount.
>
> On Feb 26, 2004, at 8:55 AM, Tom Krehbiel wrote:
>
>> David,
>>
>>>> Good point, I didn't think it through. With multiple instances of
>>>> rivet running locking would be a problem. Putting a file per session
>>>> in a session subdirectory on the server should still be ok for a
>>>> quick and dirty session store.
>>>
>>> I think even that would require locking though, so we'd need to either
>>> require TclX or build in some locking code ourselves.
>>
>>
>> Locking might be a good idea but I can't think of any case where a
>> session would conflict with itself, unless the session key was
>> corrupted. Session clean up (when a session goes away) is a problem
>> that has to be dealt with but it's a problem with databases too.
>>
>> Tom K.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Karl Lehenbauer <ka...@sc.com>.
Locking should not actually be necessary as long as the session IDs are
unique, as the filenames will be based on the session IDs. And they
oughta be unique because they're based on an md5 hash of a bunch of
different, changing stuff.
Cleanup is handled the same way it is handled in php's sessions. A
certain percentage of the calls to get a session ID (by default, 1%)
result in a cleanup. With SQL the cleanup is a delete from table where
session age > a day. For file-based sessions, it's the same deal, only
it's done by driving through all the files and deleting ones whose
modify time is greater than a certain amount.
On Feb 26, 2004, at 8:55 AM, Tom Krehbiel wrote:
> David,
>
>>> Good point, I didn't think it through. With multiple instances of
>>> rivet running locking would be a problem. Putting a file per session
>>> in a session subdirectory on the server should still be ok for a
>>> quick and dirty session store.
>> I think even that would require locking though, so we'd need to either
>> require TclX or build in some locking code ourselves.
>
> Locking might be a good idea but I can't think of any case where a
> session would conflict with itself, unless the session key was
> corrupted. Session clean up (when a session goes away) is a problem
> that has to be dealt with but it's a problem with databases too.
>
> Tom K.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
> For additional commands, e-mail: rivet-dev-help@tcl.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by "David N. Welton" <da...@dedasys.com>.
Karl Lehenbauer <ka...@sc.com> writes:
> I've started looking at it. It's a little depressing. There aren't
> a whole lot of places where DIO is called, so at least that's a
> relief. But, you know, it's so clean with SQL and then to do it
> with files, it's got to all be handled explicitly, like a pre-SQL
> 1970s COBOL program or something. And there's the issue of
> rewriting the file when a new variable is added, or having multiple
> files in a directory (I'm talking about cached session data), etc.
Well how about using SQLlite? I think it's under a BSD license,
meaning we can redistribute it. I think it in turn uses text files or
something as a backend, but at least you wouldn't have to tweak the
interface so much.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Damon Courtney <da...@your.unreality.com>.
> This is a terrific idea. This would make stuff like "DIO store" and
> "DIO fetch" work. I assume it wouldn't be able to do "delete from
> session_cache_table where timestamp 'now' - session_update_time >
> interval '7200 seconds';"
Hrmm... There is a 'DIO delete' command, but it's pretty specific.
I wonder if we could make it a little better. Hrmm...
>
> > MySQL support should work just fine. I've used DIO under MySQL
> > on a few different projects, and it should be pretty functional.
> >
> I didn't mean to imply that the MySQL support was questionable, 'cuz I
> knew it was solid. What I meant to say was that sessions haven't been
> tested with MySQL, and that there might be a subtle difference in the
> SQL required to get things like the delete statement above to work vis
> a vis Postgresql.
Well, it's a little questionable since I only used it a few times,
and Andy's the only one who's used it in any real capacity. But, he
hasn't complained to me about any bugs, so it should be pretty solid.
All I ever use is Postgres, so I don't know. 0-]
I'm not sure how well the query will work in MySQL. I think that's
the major crux of abstracting a SQL class to the point where you can
truly switch databases completely without rewriting code. I don't
think we'll ever reach that point, but we can sure come damn close.
We're all pretty clever guys and some damn smart programmers.
We can come up with something. Maybe the delete command could be
extended to use the same criteria as the search command, and it would
delete all matching items from a search result. I dunno'... I'd love
it if all the basic commands (fetch, store, delete) could be truly
useful without having to use any SQL code.
Any ideas?
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Karl Lehenbauer <ka...@sc.com>.
On Mar 10, 2004, at 10:53 AM, Damon Courtney wrote:
> I was actually just going to write up a DIO class to handle flat
> text files. That way, things like this wouldn't need enhancements.
> They
> just use DIO and pick the database type. It shouldn't be that tough.
> I've written several before.
This is a terrific idea. This would make stuff like "DIO store" and
"DIO fetch" work. I assume it wouldn't be able to do "delete from
session_cache_table where timestamp 'now' - session_update_time >
interval '7200 seconds';"
> MySQL support should work just fine. I've used DIO under MySQL
> on a few different projects, and it should be pretty functional.
>
I didn't mean to imply that the MySQL support was questionable, 'cuz I
knew it was solid. What I meant to say was that sessions haven't been
tested with MySQL, and that there might be a subtle difference in the
SQL required to get things like the delete statement above to work vis
a vis Postgresql.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Damon Courtney <da...@your.unreality.com>.
> I've started looking at it. It's a little depressing. There aren't a
> whole lot of places where DIO is called, so at least that's a relief.
> But, you know, it's so clean with SQL and then to do it with files,
> it's got to all be handled explicitly, like a pre-SQL 1970s COBOL
> program or something. And there's the issue of rewriting the file when
> a new variable is added, or having multiple files in a directory (I'm
> talking about cached session data), etc.
>
> I'm toying with the idea of creating a new class that simply manages
> the storage for sessions. That way no ugliness would creep into the
> session class itself, which right now is not ugly at all, at least in
> my opinion. Yeah, I think that's the ticket.
I was actually just going to write up a DIO class to handle flat
text files. That way, things like this wouldn't need enhancements. They
just use DIO and pick the database type. It shouldn't be that tough.
I've written several before.
> One small additional thing, since DIO provides a certain degree of
> abstraction among different database servers, it should be very easy to
> make sessions support MySQL. Sessions may actually work with MySQL
> with no changes at all.
MySQL support should work just fine. I've used DIO under MySQL
on a few different projects, and it should be pretty functional.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Karl Lehenbauer <ka...@sc.com>.
On Mar 10, 2004, at 3:40 AM, David N. Welton wrote:
> Any progress writing a Session backend for files?
Hi Everyone,
I've started looking at it. It's a little depressing. There aren't a
whole lot of places where DIO is called, so at least that's a relief.
But, you know, it's so clean with SQL and then to do it with files,
it's got to all be handled explicitly, like a pre-SQL 1970s COBOL
program or something. And there's the issue of rewriting the file when
a new variable is added, or having multiple files in a directory (I'm
talking about cached session data), etc.
I'm toying with the idea of creating a new class that simply manages
the storage for sessions. That way no ugliness would creep into the
session class itself, which right now is not ugly at all, at least in
my opinion. Yeah, I think that's the ticket.
I'm going out of town tomorrow and won't be back until early next week.
Pretty much zero chance I'll get to work on it before then.
One small additional thing, since DIO provides a certain degree of
abstraction among different database servers, it should be very easy to
make sessions support MySQL. Sessions may actually work with MySQL
with no changes at all.
Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Tom Krehbiel <to...@motorola.com>.
David,
> Tom Krehbiel <to...@motorola.com> writes:
>
>>Locking might be a good idea but I can't think of any case where a
>>session would conflict with itself, unless the session key was
>>corrupted. Session clean up (when a session goes away) is a problem
>>that has to be dealt with but it's a problem with databases too.
>
> I guess you and Karl are right... but... couldn't multiple Apache
> instances both be trying to update the session at the same time, and
> run into problems trying to write to the file?
>
> Any progress writing a Session backend for files?
I can't give a definitive answerer because I don't have an in depth
understanding of all the ways browsers and Apache can be configured
and operate. My understanding is that a session (at least in PHP) is
bound to the connection parameters (i.e. a single instance of a browser).
As long as a single instance of a browser only talks on one channel
there shouldn't be any locking problems because the channel will only
be serviced by a single Apache instance at any given instance (at least
that's what I would expect).
Tom K.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by "David N. Welton" <da...@dedasys.com>.
Tom Krehbiel <to...@motorola.com> writes:
> Locking might be a good idea but I can't think of any case where a
> session would conflict with itself, unless the session key was
> corrupted. Session clean up (when a session goes away) is a problem
> that has to be dealt with but it's a problem with databases too.
I guess you and Karl are right... but... couldn't multiple Apache
instances both be trying to update the session at the same time, and
run into problems trying to write to the file?
Any progress writing a Session backend for files?
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Tom Krehbiel <to...@motorola.com>.
David,
>>Good point, I didn't think it through. With multiple instances of
>>rivet running locking would be a problem. Putting a file per session
>>in a session subdirectory on the server should still be ok for a
>>quick and dirty session store.
>
> I think even that would require locking though, so we'd need to either
> require TclX or build in some locking code ourselves.
Locking might be a good idea but I can't think of any case where a session would
conflict with itself, unless the session key was corrupted. Session clean up
(when a session goes away) is a problem that has to be dealt with but it's a
problem with databases too.
Tom K.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by "David N. Welton" <da...@dedasys.com>.
Tom Krehbiel <to...@motorola.com> writes:
> Good point, I didn't think it through. With multiple instances of
> rivet running locking would be a problem. Putting a file per session
> in a session subdirectory on the server should still be ok for a
> quick and dirty session store.
I think even that would require locking though, so we'd need to either
require TclX or build in some locking code ourselves.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Tom Krehbiel <to...@motorola.com>.
David,
<snip>
> Hrm, Metakit is one possibility, but I don't think it does locking,
Good point, I didn't think it through. With multiple instances of rivet running
locking would be a problem. Putting a file per session in a session subdirectory
on the server should still be ok for a quick and dirty session store.
> which is really pretty important. I think SQLite is maybe a bit
> better for our purposes.
<snip>
FYI: I found out that postgreSQL exists on one of our subnets (in another
state). Right now I'm trying to determine if any of the header files still exist.
Tom K.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by "David N. Welton" <da...@dedasys.com>.
Tom Krehbiel <to...@motorola.com> writes:
[ Back from FOSDEM... cool conference! ]
> Another possibility would be to use a MetaKit database for the
> storage of session information. It is a light wait database that
> would be good for this application. If you use starkit technology
> you will get MetaKit for free just by using the tclkit
> executable. Creating a Rivit starkit would eliminate the need for
> compilation by the end user (shared librarys would be stored in the
> starkit).
Hrm, Metakit is one possibility, but I don't think it does locking,
which is really pretty important. I think SQLite is maybe a bit
better for our purposes.
I don't think Rivet would work that well as a starkit, first and
foremost because Apache would have trouble loading it!
On the other hand, I think it might be interesting to give Rivet the
possibility to use starkits... That could prove to be a cool way to
distribute web apps.
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by Tom Krehbiel <to...@motorola.com>.
David N. Welton wrote:
<..snip..>
>>New-- In PHP the default session handling store is done in a file(s)
>>on the server. It seems to me this would be a good starting point
>>for a session system in Rivet and would allow new users (such as
>>myself) to evaluate Rivet without requiring the initial installation
>>of PostgresSQL. Storage and recall of keyword-value pairs for the
>>session using array get and put should be trivial unless there is
>>something I'm missing.
>
>
> That's something I would like to see too. Stuff that "just works" is
> good. Karl, what are the steps necessary to make this happen? Damon
> seems to have an idea that DIO could be made to work with the
> toy/experimental DB I hacked together, which is pure Tcl. Maybe that
> would be the way to go instead of using a file, because Tcl can't lock
> files (and it doesn't seem that 1.3 exports that functionality).
Another possibility would be to use a MetaKit database for the storage of
session information. It is a light wait database that would be good for this
application. If you use starkit technology you will get MetaKit for free just
by using the tclkit executable. Creating a Rivit starkit would eliminate the
need for compilation by the end user (shared librarys would be stored in the
starkit).
Tom K.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Session Quesions/Comments
Posted by "David N. Welton" <da...@dedasys.com>.
Tom Krehbiel <to...@motorola.com> writes:
> The following question was posed as part of my comments on the
> documentation, but I wanted to expand on it a little since the
> session handling is apparently new. As background to what follows,
> my experience is limited to session handling in PHP and doing myself
> a long time ago.
> From a previous email--
> I didn't understand the discussion of the session database
> interface. I'm familiar with RDMS systems but the discussion
> concerning table generation appears to be Postgres specific. I
> worked with Postgres a little a long time ago but don't remember
> enough to be sure. Examples using SQL would be better at this point
> in my opinion. I also don't understand your reference to DIO. I
> checked google and didn't get anything useful and the MySQL web site
> same result. Is DIO some type of API definition like ODBC?
DIO is the database abstraction layer. There are some incomplete docs
in doc/packages/dio, which I need to merge with the main docs.
> New-- In PHP the default session handling store is done in a file(s)
> on the server. It seems to me this would be a good starting point
> for a session system in Rivet and would allow new users (such as
> myself) to evaluate Rivet without requiring the initial installation
> of PostgresSQL. Storage and recall of keyword-value pairs for the
> session using array get and put should be trivial unless there is
> something I'm missing.
That's something I would like to see too. Stuff that "just works" is
good. Karl, what are the steps necessary to make this happen? Damon
seems to have an idea that DIO could be made to work with the
toy/experimental DB I hacked together, which is pure Tcl. Maybe that
would be the way to go instead of using a file, because Tcl can't lock
files (and it doesn't seem that 1.3 exports that functionality).
--
David N. Welton
Consulting: http://www.dedasys.com/
Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
Apache Tcl: http://tcl.apache.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org