Re: Fixing Media Collections once and for all

[James M Snell]

Kyle Marvin wrote:
> On 4/25/06, Joe Gregorio <[EMAIL PROTECTED]> wrote:
>> On 4/25/06, Kyle Marvin <[EMAIL PROTECTED]> wrote:
>>> - There are some unexplained life cycle issues.    In particular, what
>>> happens if I issue a DELETE to the enclosure-edit resource and remove
>>> the media.   Is the associated entry removed from the collection
>>> automatically, or is the client required to issue a DELETE on the
>>> "edit" link too?   In the first use case above (media drop-box), then
>>> it seems like a single DELETE removing both has to be the way it
>>> works, as there would be no "edit" link if there is not editable
>>> metadata.
>> I agree a single DELETE is the way it should work. To keep things
>> consistent I think that DELETE must be directed at the metadata
>> and not the enclosure-edit resource.
> 
> This won't work if the metadata isn't editable (i.e. no "edit" link on
> the returned entry).  So if you think it should be a single DELETE, it
> seems like doing it on the "enclosure-edit" resource is the only
> approach that can work for both read-only and read-write media
> metadata cases.
> 

If the metadata isn't editable, should the media resource be editable?

FWIW, in our implementation, the enclosure-edit URI is the same as the
entry edit URI.  We differentiate based on what media-type is PUT on the
update. If the client PUT's an Atom Entry Document, we update the
metadata; if the client PUT's any other media type other than
multipart-related, we update the media resource; if the client PUT's a
multipart-related, we assume that one part contains the Atom entry and
another part contains the media resource, so we update both.  The DELETE
is only ever issued on a single URI.

>>> - Eric's suggestion that perhaps using "alternate" instead of
>>> "enclosure" for the public/read-only version of the media is
>>> reasonable to me.   In the case of an Atom entry that refers to media,
>>> this seems to fit the definition of the "alternate" per RFC4287:  "an
>>> alternate version of the resource described by the containing
>>> element.".   Otherwise, we have validation issues in the media dropbox
>>> case or if the client doesn't set 'content' and/or the server has to
>>> synthesize a content element to make it valid.
>> An empty content element, while not very helpful, is still valid.
> 

FWIW, our implementation uses alternate AND enclosure for media entries.
 I would be perfectly fine using alternate and edit-alternate, however,
this gets just a bit tricky in cases where the server generates
alternate views for a post.  For instance, you could end up with entries
like:

  <entry>
    ...
    <link rel="alternate"
          type="application/xhtml+xml"
          href="http://example.org/foo.xhtml"; />
    <link rel="alternate"
          type="image/png"
          href="http://example.org/foo.png"; />
    <link rel="edit-alternate"
          type="image/png"
          href="http://example.org/edit.cgi?name=foo.png"; />
    ...
  </entry>

This works, of course, and is perfectly valid from a format point of
view, but experience with various implementations demonstrates that
handling multiple alternate views is problematic at best.

> Using an 'atomOutOfLineContent' reference to the media public url as
> atom:content (unless/until explicitly set by the client) is another
> option.
> 

This doesn't work for us.  We're using content for other stuff.

- James