JP> Specifically, if seems that we want to accomplish the following three
JP> things:
JP>
JP> 1) identify sessions from server logs (esp. from firewalled domains)
I believe this concept is too restricted. We (I, at least) want to be able
to identify sessions, but doing it from server logs is much too slow. As
soon as the client connects, I need to know where they came from because
since all my objects are dynamically generated, I can use that information
to customize the current page. I've thought about doing this via hacked up
URLs, and although I will probably do this on the short term, Session-IDs
are a much cleaner, long-term solution.
It could be argued that what I really want is your third goal:
JP> 3) freely pass data as first class objects between client/servers
but I think this is incorrect. I don't really want to passing the state
information back and forth all the time. This information could get rather
large, and if I have CPU cycles to burn, I'm willing to store the state
server-side since it will improve performance, and that's of added value to
my customers.
I also think that your claim that:
JP> The first issue is quite doable without any modifications to existing
JP> protocols (I wrote code a year and half ago, before the referrer
JP> field, that accomplishes this with a high degree of certainty that the
JP> paths inferred are the paths actually traveled. See "WebViz: A Tool
JP> for WWW Access Log Visualization" from the First WWW Conference
JP> Proceedings).
is flawed. We're not talking about identifying sessions to some significant
probability; we'd really like to know almost positively. I don't have time
to look at your paper right now; how well does it performance in caching and
firewall setups (as with the major commericial services (AOL, Prodigy, and
so forth))?
-- Jared_Rhine@hmc.edu / HMC / <URL:http://www.hmc.edu/~jared/home>"Be not angry that you cannot make others as you wish them to be, since you cannot make yourself as you wish to be." - Thomas A. Kempis