Hm this implies pulling a lot of MIME-related dependencies to just generate / parse this header properly.
javax.mail.internet.ParameterList does the work except that the Sun implementation needs a system property for RFC 2231 to be activated, doh. geronimo-javamail_1.4_spec has an implementation as well, but I'm afraid of classloader clashes. If we want to go the Content-Disposition route, then I think we'll have to copy what's needed from Geronimo. Florent On Wed, Feb 9, 2011 at 11:30 AM, Florent Guillaume <[email protected]> wrote: > Good points. > Content-Disposition is good; while it's mostly used for download, it's > also used on multipart HTML file uploads, so there's precedent. > I'll try to find a suitable RFC 2231 implementation. > > Florent > > On Tue, Feb 8, 2011 at 9:37 PM, Florian Müller > <[email protected]> wrote: >> 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 >>> >> >> > > > > -- > Florent Guillaume, Director of R&D, Nuxeo > Open Source, Java EE based, Enterprise Content Management (ECM) > http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87 > -- Florent Guillaume, Director of R&D, Nuxeo Open Source, Java EE based, Enterprise Content Management (ECM) http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
