Generating the header shouldn't be that difficult. We only want the
"filename" subset of Content-Disposition. The disposition parameters are
all optional. So we can skip the others. I don't think we need a library
for that.
Parsing is more tricky. Since we only want the filename bit and can
ignore all others we might content ourselves with a rather simple
parser. The major difficulty is to track the quotes properly.
- Florian
On 09/02/2011 11:26, Florent Guillaume wrote:
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
