Hmmm. I put up my 3 interesting packages:
www.nsstuff.zoro.tcl.pl (nice domain - a better one is www.nsstuff.nsession.zoro.tcl.pl) These domains are just a nice trick done by nssmartvh :) Wojciech Kocjan wrote: > Dossy wrote: > >> On 2001.12.23, Wojciech Kocjan <[EMAIL PROTECTED]> wrote: >> >>> Hmmm. When a user logs in, he gets a new cookie with a new SID. So both >>> of them send the same SID and both of them will have the same session >>> settings/data. This shouldn't be a problem. I want to implement nsession >>> eval (similar to ns_cache eval) so that data can (but does not have to) >>> be modified by one thread at a time. >> > > >> The problem is that there can be activity BEFORE the user logs in >> that gets tracked to the "anonymous" session ... and that will get >> lost once they log in. > > > > I set expires on the cookie to 2 weeks by default. So after logging in > the user usually remains logged in as long as he/she visits my site once > in a while. > >> That's an idea. Sessions with hitcount < 2 don't get saved >> to persistent storage. Cool! Thanks for the idea. > > > > Sounds good. > >> The downside is that an actual anonymous user that only hits >> the site once (creates a session, then closes their browser >> or links away from the site) won't get their session saved >> either. > > > > Who cares about them? ;-) > > I do not want to use sessions to track users > > >> Since I'm going through the trouble of creating a new session >> regardless, I might as well save them anyway, and just clean >> them up in the expiry process. Doesn't really cost me that >> much, I don't think. > > > > > >>>> 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.) >>>> >>> Hmmm, very odd. I mostly use www.domain.pl (even used http://zoro2.org) >>> and NN4 did not make any problems at all for me. >>> >> I found out the problem. If the URL is http://foodomain.com/ (one >> period) and your Set-Cookie: has "domain=.foodomain.com" or >> "domain=foodomain.com" it won't set the cookie. Remove the >> "domain=" attribute entirely from the Set-Cookie: and it works >> for NS and IE. > > > > I didn't use domain= - sad to admit it, but never understood what does > it exactly do. > >>>> Hmm. I'd be curious to try some benchmarks of my version (which is >>>> pure Tcl) vs. yours in C. >>>> >>> A simple helloworld+counter was about 5% slower than a simple hello >>> world when I told ab to send session by hand. >> >> Wait, do you mean you actually benchmarked your implementation vs. >> my implementation, and mine is 5% slower? Or what do you mean? > > > > hello.adp: > <%="Hello world"%> > hello_c.adp: > <% nsession init %> > <%="Hello world"%> > > This is quite what you assumed... > >> I think you mean that you tested a plain HTML page vs. a page that >> uses YOUR session management to implement a counter, and you found >> that adding the counter was 5% slower? > > > > Yeap. > > >>> btw Do you know any good http benching software that supports cookies in >>> a convenient way? :) >> >> I _think_ WebLoad (by whoever owns it today ... RadView, Mercury, >> Platinum, I can't keep up) will use cookies intelligently. > > > > RadView - and it's commercial, darn :( > > I've been thinking about writing a small tool like ab in Tcl, but I'm > afraid that Tcl could cause it not quite accurate... > >>>> I'd be willing to bet that the ability >>>> to extend my implementation rapidly will outweigh any performance >>>> gains your C implementation might offer. >>>> >>> That depends. I learnt that Tcl+C offers the best >>> performance/exdending_speed compromise (I wrote a quite fancy name-based >>> vhosting module that way - it uses tcl to resolve domain->path and >>> caches it - under 1% performance loss to not using the module). >>> >>> Anyway, I assumed that sessions aren't that complex and can be written >>> in pure C. We can bench and compare things if you want to. I'm also >>> curious about the difference in performance. >>> >> >> Well, when you have some free time, we can put together some tests. > > > > This means on january :-) > >>>> Lets put our heads together, and try getting something that people >>>> can start using -- not everyone needs or wants to use ACS ... >>>> >>> Definitely so. I tried OpenACS but it looked a bit too complex for me >>> ;-) >>> >>> Besides, I'd like to see some modules that allow half the stuff ACS does >>> - like news, forums, downloads, but as a nice Tcl module - so that I can >>> put something like <%=[z.news::latest]%> in my code :) >>> > >> Well, I think Jerry's working on some blog stuff, which depending on >> how clean the implementation is, could probably be repurposed to do >> the kind of stuff you're thinking of. > > > > > >> Otherwise, I might get around to doing it. Write a spec. for what >> you want on the AOLserver wiki, and maybe in 14 months I'll get >> around to implementing it. *chuckle* > > > > rotfl ;-) > > I wrote a nice thingie for news - uses ns_cache, my own XML module, TBC > for more efficient code loading and so on. > > BTW What shocked me in a way was that when I rewrote namespace.tcl to > append "[list load libtbcload.so];[list source $tbcfilename]" it gave > the engine about 5-10% boost :) - even though it required opening a > file, decoding TBC and so on. And what's most interesting is that TBC > was never written with speed in mind. > > -- > WK > > -- > WK > > >
