On 4/29/06, Kyle Marvin <[EMAIL PROTECTED]> wrote:
Note: that composition and hybrid content + media* entries would still
be possible with the APP core, it just requires that the client does
the composition to build an entry that is composed up using references
to entries that refer to singular resources.   This model would be
guaranteed to work on *all* APP implementations, other extensions or
vendor-specific approaches (like multipart) are just optimizations to
get to this end result, but let's provide one clear, atomic mechanism
that is guaranteed.

+1 to not optimising the protocol for overly complex scenarios. Keep
  simple things simple and complex operations possible.

- I'm OK with the notion that a collection w/out an app:accept
elements means it is an entry-only collection.   After all, the
approach of this PACE fundamentally makes the store more entry-centric
since all resources now have an entry representation.   On the flip
side, if we did match the http accept semantics, then we should
probably match its syntax too (including qvalues and
accept-extensions).  I'm not convinced that we need that.

I don't believe qvalues are useful, if I am going to add a file to a media
collection the client needs a yes or no answer as to whether or not
it will be accepted. Preference doesn't enter into the equation.

  Correspondingly, it might also be helpful to have the Title in the
request actually impact the response.

+1

  -joe

--
Joe Gregorio        http://bitworking.org

Reply via email to