- From: James Pitkow <pitkow@cc.gatech.edu>
- Date: Fri, 21 Jul 1995 23:39:13 -0400 (EDT)
- To: burchard@geom.umn.edu
- Cc: www-talk@w3.org
Paul writes: > As John also tried to explain, these are non-problems. The server 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.
Received on Friday, 21 July 1995 23:42:20 UTC