Don't bark at me. John's initial proposal was flawed; he had a scheme
but failed to explicate it. I merely pointed this out. He then
modified it accordingly.
> can just use a persistent counter with enough bits to be unique for
> a few millennia (64 bits would more than suffice at your hit rate),
> and then allocate these values to the individual server threads in
> blocks large enough that synchronization overhead becomes
> irrelevant.
Yup, and they thought the initial IP allocation scheme would scale well
too. How does your solution handle multiple hosts? and situations
where IPs are hashed to different machines for the same object space
like at NCSA and other large sites?
> My objections to session-ID are more fundamental. I feel we are
> about to create a crippled mini-HTTP-within-HTTP for special "small"
> objects stuffed into HTTP headers. I will try to put together an
> alternate proposal based on HTTP's existing Link: capability.
Ahh, this is what I said two days ago about treating this information as
a first class data object, not a single part header and what I wrote
at the beginning of this thread:
You ever get the feeling of a dog chasing it's own tail?
Regards,
Jim.