Subject: Re: PaceURINomenclature and PaceOnlyMemberURI - msg#00628

Previous Message by Date: click to view message preview

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 >>> >>> >> >> >> >

Next Message by Date: click to view message preview

Re: PaceContentNegotiationSection

> >Ok, so a GET to http://example.com would specifying Accept: >application/atomserv+xml;q=1.0 would result in a redirect (permanent or >temporary) to the appropriate service document for the authenticated >user. Am I missing something? > Yes, you are. If a request comes in which has a higher q-value for APP than it does for HTML the response is index.atomsrv, if HTML wins out the response is index.html, no redirection involved. The request for index.atomsrv is then negotiated on the basis of AUTH headers (which would be the starting point if HTML representations weren't involved), so the request for index. atomsrv is really a request for user.atomsrv, which is what I return in Content-Location and classify accordingly as a URI collision since the request was for /index.something not /user.anything -- the resource is varied across requests instead of the representation being varied across requests. -EJB >> Really, I thought this was the purpose of the MIME type, under the examples >> others have given there's no reason I can fathom that it can't be an >> existing XML MIME type of some sort, 'applicaton/xml' or such. The only >> reason I could deduce for it was to allow negotiation. >> > >There are several uses for the mime type, conneg is just one. > >- James >

Previous Message by Thread: click to view message preview

Re: PaceURINomenclature and PaceOnlyMemberURI

2006/8/19, Elias Torres: Kyle Marvin wrote: > > For the record, POMU doesn't prevent you from splitting them... in > fact it says *nothing* about the self URI. > Hmmm.. That's a good point of view. Is the definition of 'self' in an earlier today that it must the full Atom representation of the entry correct? No If so, wouldn't that say that client developers can always use it as a fallback mechanism *if* the member URI returns 409 let's say? Definitely no. Actually, 'self' would have been called 'content-location' as it's really what it has been designed to be: putting the Content-Location or request URI into the feed or entry, so that if headers or the request-URI is not communicated to, say, the aggregator, this one has the feed URI nonetheless. -- Thomas Broyer

Next Message by Thread: click to view message preview

Re: PaceURINomenclature and PaceOnlyMemberURI

On 8/18/06, Elias Torres <elias-teabWVY4yyH1P9xLtpHBDw@xxxxxxxxxxxxxxxx> wrote: Kyle Marvin wrote: > On 8/18/06, Elias Torres <elias-teabWVY4yyH1P9xLtpHBDw@xxxxxxxxxxxxxxxx> wrote: >> >> I think they are both easy to implement but I lean towards >> PaceURINomenclature because it gives me the option of separating my >> edit-uri from self-uri. > > For the record, POMU doesn't prevent you from splitting them... in > fact it says *nothing* about the self URI. > Hmmm.. That's a good point of view. Is the definition of 'self' in an earlier today that it must the full Atom representation of the entry correct? If so, wouldn't that say that client developers can always use it as a fallback mechanism *if* the member URI returns 409 let's say? I think the intention would be that you do another GET on the Member URI to get the current representation (that your PUT conflicted with) and try to locally resolve the differences. This is especially important if using ETags, because you need the ETag value (from that GET) for the matching in the PUT to have a chance to succeed and avoid any lost updates. In the case of GData, we actually return the current (server) representation in the 409 response entity body, but I'm not sure I'd recommend that generally. For an ETags-based server, this isn't useful (beyond logging) because you'd have the current resource rep but not its ETag.