On 2001.12.23, Wojciech Kocjan <[EMAIL PROTECTED]> wrote: > Ok, I'll explain how I do it currently with mod_dtcl in detail:
Neat. I've implemented mine very similiarly to yours. No merging when users log in, and logout just expires the session ID cookie. I call mine "UID" -- I'll probably make the cookie name configurable soon. There's no reason to create a new session ID -- a new one gets created when the user accesses another page since their old session ID cookie was expired. > The basic idea is that if someone cares about his session data, he'll > log in. If he doesn't have a user, he'll eventually create one. My problem is if the same user logs in from two different places ... how do you merge the two sessions. Maybe that's an application-specific problem and not something you can solve in a general fashion... > Also, my previous implementation had a cleanup algorithm and expire > parameter. The new one is not even close to being final version, so a > lot is missing. Hopefully soon I'll get around to writing a scheduled proc that'll clean up the in-memory session data (held in nsv structures) and an expire proc that purges old session data after inactivity. > The problem is that currently I do not even try to check if a user > accepts cookies - this can create a mess. No kidding. A new session will be created every time they access a page. Absolutely miserable. I ran into a browser bug with Netscape ... if your webserver is just foodomain.com (and not www.foodomain.com) Netscape won't let you set a cookie. It looks for two periods in a hostname if it's one of the "big 7 TLDs" (you know, COM, NET, ORG, etc.) and three periods if it's a ccTLD (.nj.us, .it, etc.) but Microsoft Internet Explorer doesn't have this problem (security hole?) ... yet again, why Netscape 4.x sucks so bad ... (Of course, there's no port of MSIE to Linux, argh.) > I'll try and put it online sometime soon (hey, it's christmas, don't > have too much time :). I know ... but I'm finding more time now since I'm not working, so I figured I'd take advantage of it. > Also, in my previous implementation, there was no nsv/permament storage. > My new code uses Ns_Mutex and my own code to store data and has a > separate thread for synchronization to disk - if the sessions go above a > predefined limit, some of them will be saved on disk. Because sessions are mostly read-only (mine are, at least) I have it set so that any writes to session data cause a write to persistent storage. If this poses to be a bottleneck (or a concurrency issue) I'll address it later. > Also, I never used my nsession module, so I suppose it would be wiser to > "join forces". I need to be able to connect sessions with users and > store strings/integers (for now I store fixed size strings - not very > efficient but quite fast) and use 32bit checksums for faster searching > through data. Hmm. I'd be curious to try some benchmarks of my version (which is pure Tcl) vs. yours in C. I'd be willing to bet that the ability to extend my implementation rapidly will outweigh any performance gains your C implementation might offer. Lets put our heads together, and try getting something that people can start using -- not everyone needs or wants to use ACS ... -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
