Re: By way of example.

Bear in mind, for these examples example.com serves only one MIME type, 
application/atomserv+xml.

User requests:

http://example.com/service

Server returns representation of available collections, at /service, no prob.

User 2 requests:

http://example.com/service

Server returns representation of available collections, at /service, which is 
not (necessarily) the same document the first user received, is it?

So if you parameterize the URL in the returned Content-Location like so:

http://example.com/service?user=1
http://example.com/service?user=2

Then you are serving two resources at the same URI but at least subsequent 
requests don't renegotiate /service.

I am returning /userid.atomsrv, an entirely different take on implementing 
the spec which still results in the same collision condition.

User 1 requests:

http://example.com/index.atomsrv

Server returns /user1.atomsrv

User 2 requests:

http://example.com/user2.atomsrv

Server returns /user2.atomsrv

I'm serving two different resources, user1.atomsrv and user2.atomsrv, at the 
same URI index.atomsrv.  So please, show me how to implement this for 
multiple users without it resulting in a URI collision.

-EJB

>-----Original Message-----
>From: Tim Bray [mailto:Tim.Bray-UdXhSnd/wVw@xxxxxxxxxxxxxxxx]
>Sent: Friday, August 18, 2006 03:08 PM
>To: eric-MkmoNbc1SAncr/OS1auqaA@xxxxxxxxxxxxxxxx
>Cc: 'Thomas Broyer', atom-protocol-O6w3ZxSwtmQ@xxxxxxxxxxxxxxxx
>Subject: Re: By way of example.
>
>On Aug 18, 2006, at 2:42 PM, Eric J. Bowman wrote:
>
>> Which is all entirely irrelevant -- don't you see that whether or  
>> not I
>> locate the service document at http://example.com/index.atomsrv - 
>> or- if I
>> locate it at http://example.com/introspection...
>>
>> It is still a URI collision for ANYONE who implements it.
>
>No, I don't see.  Please explain the URI collision.  If you have two  
>URIs for your service doc, so what?  I believe that there's a great  
>big hairy problem that is plain as day to you, but I'm really having  
>trouble understanding it.
>
>> Again, what are YOU GUYS returning in your Content-Location which  
>> does not
>> constitute the same exact URI collision I see in my implementation?
>
>Content-location on which APP operation?
>
>I'm really trying to figure this out. -Tim
>
>