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 Karl Lehenbauer <ka...@sc.com> on 2004/01/06 07:45:02 UTC
Committed session management stuff
Howdy Y'all...
I've committed a from-scratch re-implementation of Superconnect's
session management stuff for Rivet under the Apache license.
It's pretty good, I think. The docs right now are a README file, but I
think you can read through it and actually get sessions going.
See what you think, and all feedback is appreciated.
Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Committed session management stuff
Posted by Karl Lehenbauer <ka...@sc.com>.
On Jan 6, 2004, at 5:06 PM, David N. Welton wrote:
> Damon Courtney <da...@your.unreality.com> writes:
> Is it possible to use "url-style" sessions to avoid the use of
> cookies?
That is one thing I haven't looked into, that the php session stuff
does do. If we had this, we would have a pretty much 100% equivalent
implementation of the php stuff. It would be no problem to identify a
session coded into a URL, but the URL would need to be rewritten during
webpage processing, without the session ID, so Apache could locate the
webpage, etc, right? Isn't this the kind of thing mod_dtcl does, or
does this facility exist in Rivet?
Mostly the session stuff only uses the simple dio fetch and store
stuff. About the only even slightly tricky stuff is the garbage
collection code, where it does a delete with a slightly complex "where"
clause, and relies on cascading deletes to implicitly remove any
session cache data when a session is removed.
>> Karl and I have talked a couple of times about implementing a
>> really solid CMS system that could easily be distributed with Rivet,
>> and I think should. That's in the future, but it's something to
>> think about. A system like that will definitely require a present
>> SQL server.
Yeah, with these sessions, a login system should come together pretty
quickly. Basically all you need is a user table with user names and
passwords, and a login table where you store user IDs with session IDs.
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Committed session management stuff
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney <da...@your.unreality.com> writes:
> > Is it possible to use "url-style" sessions to avoid the use of
> > cookies?
> That's definitely something I'd like to see added.
Yes, this is something WebSH does very nicely. Worth looking at and
borrowing the code where applicable.
> > Yeah, I tried fiddling around with the 'simpledb' Tcl code, but I
> > think sqlite is probably a better bet.
> > Does it handle concurrent accesses well? How so?
> As of the latest versions, yes. It handles concurrent read
> access really well with file-locking access on writes and the like.
> Not the MOST efficient thing in the world, but I think it works for
> most of the uses we're talking about. Anyone with more robust needs
> should be using a more robust database.
Is it cross-platform?
> > I agree with you though... It took a bit of fiddling to get this
> > working with Postgres. I would really like to have an option for
> > people to have it "just work" out of the box, and I don't think
> > that is ever going to work with Postgres.
> There's also Metakit to consider. It's a simple matter to write
> a DIO interface to a new database type, and Karl has already written
> all the session code using DIO. I'm even going to write a DIO
> interface to your simpledb. 0-]
> > Is it possible to package up the different database backends
> > separately so that they each occupy their own file and don't
> > clutter things up if we have a lot of them?
> We could easily move DIO's separate database classes into
> separate files. I kept them all in one initially so that I could
> move it around easily. As we add more though, I think it's better
> to split them out. IE:
> dio.tcl
> mysql.tcl
> oracle.tcl
> postgresql.tcl
Yeah, good plan.
> Etc... It's really a no-brainer to add interfaces in DIO. One
> look at either of the already-built interfaces, and you can knock
> out a new one in an hour. As long as the code within Rivet uses DIO
> as its base for database handling, Rivet will be completely
> database-neutral. At least, that's my hpoe. 0-]
We need to publicize DIO better... I'll see what I can do.
--
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: Committed session management stuff
Posted by Damon Courtney <da...@your.unreality.com>.
> Is it possible to use "url-style" sessions to avoid the use of
> cookies?
That's definitely something I'd like to see added.
> Yeah, I tried fiddling around with the 'simpledb' Tcl code, but I
> think sqlite is probably a better bet.
>
> Does it handle concurrent accesses well? How so?
As of the latest versions, yes. It handles concurrent read access
really well with file-locking access on writes and the like. Not the
MOST efficient thing in the world, but I think it works for most of
the uses we're talking about. Anyone with more robust needs should be
using a more robust database.
> I agree with you though... It took a bit of fiddling to get this
> working with Postgres. I would really like to have an option for
> people to have it "just work" out of the box, and I don't think that
> is ever going to work with Postgres.
There's also Metakit to consider. It's a simple matter to write
a DIO interface to a new database type, and Karl has already written
all the session code using DIO. I'm even going to write a DIO
interface to your simpledb. 0-]
> Is it possible to package up the different database backends
> separately so that they each occupy their own file and don't clutter
> things up if we have a lot of them?
We could easily move DIO's separate database classes into separate
files. I kept them all in one initially so that I could move it around
easily. As we add more though, I think it's better to split them out.
IE:
dio.tcl
mysql.tcl
oracle.tcl
postgresql.tcl
Etc... It's really a no-brainer to add interfaces in DIO. One look
at either of the already-built interfaces, and you can knock out a new
one in an hour. As long as the code within Rivet uses DIO as its base
for database handling, Rivet will be completely database-neutral. At
least, that's my hpoe. 0-]
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org
Re: Committed session management stuff
Posted by "David N. Welton" <da...@dedasys.com>.
Damon Courtney <da...@your.unreality.com> writes:
> > I've committed a from-scratch re-implementation of Superconnect's
> > session management stuff for Rivet under the Apache license.
Wow, cool! Thanks, Karl!
> > It's pretty good, I think. The docs right now are a README file,
> > but I think you can read through it and actually get sessions
> > going.
> > See what you think, and all feedback is appreciated.
Is it possible to use "url-style" sessions to avoid the use of
cookies?
> Looks really complete. 0-] I will definitely get some mileage
> out of it.
> I definitely think with this commit that we need to add a
> default database to Rivet, and I'm pretty sure SQLite is the only
> real candidate. It's small, portable, unencumbered by license and
> doesn't require a separate server process to get the job done.
Yeah, I tried fiddling around with the 'simpledb' Tcl code, but I
think sqlite is probably a better bet.
Does it handle concurrent accesses well? How so?
I agree with you though... It took a bit of fiddling to get this
working with Postgres. I would really like to have an option for
people to have it "just work" out of the box, and I don't think that
is ever going to work with Postgres.
> Now, obviously, someone with real database needs can run
> something else, but I think we should include this as the default
> database for code like this that needs SQL. I know for a fact that
> more and more code that becomes part of Rivet will require a SQL
> server of some kind.
> Karl and I have talked a couple of times about implementing a
> really solid CMS system that could easily be distributed with Rivet,
> and I think should. That's in the future, but it's something to
> think about. A system like that will definitely require a present
> SQL server.
> Of course, with DIO, any application will be trivial to switch
> to another SQL database with just a little switch in the
> arguments. 0-]
Is it possible to package up the different database backends
separately so that they each occupy their own file and don't clutter
things up if we have a lot of them?
--
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: Committed session management stuff
Posted by Damon Courtney <da...@your.unreality.com>.
> Howdy Y'all...
>
> I've committed a from-scratch re-implementation of Superconnect's
> session management stuff for Rivet under the Apache license.
>
> It's pretty good, I think. The docs right now are a README file, but I
> think you can read through it and actually get sessions going.
>
> See what you think, and all feedback is appreciated.
Looks really complete. 0-] I will definitely get some mileage out
of it.
I definitely think with this commit that we need to add a default
database to Rivet, and I'm pretty sure SQLite is the only real candidate.
It's small, portable, unencumbered by license and doesn't require a
separate server process to get the job done.
Now, obviously, someone with real database needs can run something
else, but I think we should include this as the default database for
code like this that needs SQL. I know for a fact that more and more
code that becomes part of Rivet will require a SQL server of some kind.
Karl and I have talked a couple of times about implementing a really
solid CMS system that could easily be distributed with Rivet, and I think
should. That's in the future, but it's something to think about. A system
like that will definitely require a present SQL server.
Of course, with DIO, any application will be trivial to switch to
another SQL database with just a little switch in the arguments. 0-]
D
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscribe@tcl.apache.org
For additional commands, e-mail: rivet-dev-help@tcl.apache.org