Re: By way of example.

>
>Ok, first, it would seriously help the conversation if you just simply
>stopped using the term "URI collision".
>

It was my work which was so characterized.  Since the problem I describe fits 
the definition of that term, I see no reason to change until someone 
convinces me that Mary's collection is the same resource as Joe's collection 
and that each user receives a _version_ of some master document listing 
everybody's collection (i.e. index.atomsrv).

>
>Second, what's the problem? So different users get different results
>when calling the same URI. Happens all the time.  If you navigate to the
>URI http://www.google.com/ig?hl=en, you'll see a different result than
>what I see. No big deal.
>

No, I'm sorry, that does not happen all the time.  When I dereference:

http://example.com/index.atomsrv

I should see a representation of index.atomsrv, not some other resource 
user.atomsrv which is NOT derived from the resource I dereferenced.  If I 
then dereference that URI from a different workstation and it returns 
user2.atomsrv, this is also not a representation of index.atomsrv but is also 
an entirely separate resource which bears no resemblance to user.atomsrv, 
despite sharing the same URI.

If I dereference these:

http://www.example.com/instructions?hl=en
http://www.example.com/instructions?hl=es

and the first URI returns English-language instructions for lawnmower repair 
but the second URI returns Spanish-language instructions for making a martini 
we have a problem, typically referred to as a URI collision.  If they are 
both returning instructions for the same thing we have a perfectly good use 
of content negotiation to choose the correct language representation of the 
same resource.

>
>One you know which user is invoking the service, the rest is really
>quite simple.  For instance, you can dynamically generate the returned
>entity based on the user id or you can do a permanent redirect to a user
>specific URI.
>

So until I know who the user is, my resource is a script which sniffs AUTH 
header and redirects according to some pattern.  So the resource here:

http://example.com/service

Is some sort of executable RPC which determines how to redirect the user to 
their real resource, i.e. http://example.com/user/feed.atomsrv which is not 
the requested resource in a new location, it is an entirely different 
resource in a new location.  Which means http://example.com/service is not an 
.atomsrv resource and never serves a representation of an Atom file to 
anyone.  I call that a service endpoint and question how well it can scale.

If you are dynamically generating the response to /service instead of re-
directing, what are you returning in Content-Location?  Just /service?  If 
you can't come up with some dereferenceable URI to send back after conneg, 
how can this response be properly cached?  Or, does every request for the 
service document trigger conneg at /service?

-EJB

>- James
>
>Eric J. Bowman wrote:
>> 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
>>>
>>>
>> 
>> 
>> 
>