James Holderness wrote:
James M Snell wrote:<entry> <title>A media member</title> <link href="http://example.org/public/2.png"; /> <link rel="edit" type="image/png" href="http://example.org/members/2"; /> <link rel="edit' type="application/atom+xml" href="http://example.org/members/2"; /> ... <content type="text">This is a description</content> </entry>The problem I have with this proposal is the fact that you have two separate URIs for the media resource itself - one for read-only viewing and one for editing. That flexibility may seem nice at first, but it causes all sorts of complications when you try and fit it into the rest of the APP spec.
Having the ability to separate the edit and alternate URI's is very important, particularly in cases where your public alternate URI is being served up by a content distribution network or your edit API is sitting behind a firewall.
For example, in section 5.2, which of those URIs is returned in the location header when you create a new resource? If it's the edit URI then a user wanting to post a blog entry with a cat picture needs to first post the image, then enumerate the media list to find the read-only URI to use in their post. If it's the read-only URI then most of section 5 needs to be rewritten to take that into account.
Sorry, I wasn't clear. This is *not* a proposal for merging media and entry collections. In the vast majority of cases, just as as been te expectation all along, these would be completely separate from one another. This pace does not change that. The problem you cite *already exists* in the definition of media collections in draft -07 and is the key reason why, in our implementation, we allow clients to post their media files directly to the entry collection to create an entry. This allows our server to do the association automatically without the client having to first figure out what the public URI is.
Either way sections 8, 9 and 10 all need wording to clarify that there are multiple URIs pointing to the media resource which isn't the case in entry collections. I'm not convinced all this extra complexity in the spec is worth it.
Again, this is *already* a problem. Note that section 8.3.1 says "**When creating a public, read-only reference to the member resource**, a client SHOULD use the "atom:content/@src" attribute value". Note that the spec does not state how the edit reference should be communicated... just how the public read-only reference should be made. What does it mean if the server puts an edit link in the entry representing the media resource? What does it mean if the server puts an alternate link in the entry representing the media resource? The spec doesn't say.
Anyway, I'm not -1 on the proposal, but I'm not +1 either. I don't particularly like the existing spec, but I don't think this proposal is necessarily any better in its current form.
This pace isn't designed to solve all of the problems of media collections. It is designed to at least bring some consistency between the way media and entry collections work.
- James
![http://example.org/public/2.png"](http://example.org/public/2.png"){kind=link}