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.

> >>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.
>
> How do you deal with that?
>
> Actually my code deals with it quite good - a session without any
> attributes is simply not saved at all - however it does consume memory :(

That's an idea.  Sessions with hitcount < 2 don't get saved
to persistent storage.  Cool!  Thanks for the idea.

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.

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.

Lame.

> >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?

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?

> 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.

> >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.

> >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*

-- 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)

Reply via email to