Hi Florent, The updatability of the cmis:contentStreamFileName property is not defined in the spec and might be read-only. Updates will fail, I reckon, for many repositories.
How about setting the Content-Disposition header instead? For example: Content-Disposition: attachment; filename="document.pdf" - Florian On 08/02/2011 16:03, Florent Guillaume wrote: > Hi, > > CMIS 1.0 defers to AtomPub for the implementation of the > setContentStream operation (just do a PUT on the edit-media link). But > this does not allow setting the filename directly, which makes > higher-level abstraction layers like our Document#setContentStream > Java API not symmetrical and surprising to users. > > I see several things we could do: > 1. pass the filename in an additional Slug: header as suggested by > AtomPub (but only suggested for POSTs to collections), > 2. pass the filename as an additional&filename=foo.png in the URL (or > x-opencmis-filename=...), > 3. in the client library do an additional call to edit the > cmis:contentStreamFileName (suggested by AtomPub 9.6.1 in the > examples, "The client can edit the metadata for the picture..."). > > For the first two this would have to be done both on the client side > and on the server side so that we interoperate at least with > ourselves. The question is, which of those would likely be adopted by > others as "extensions", and maybe mentioned in CMIS 1.1 or 2.0. > The last one involves an additional round trip to the server. > > Thoughts? I'm inclined to implement 3. for now, in > o.a.c.o.client.bindings.spi.atompub.ObjectServiceImpl.setContentStream. > > Florent >
