chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florent Guillaume ...@nuxeo.com>
Subject Re: setting filename with AtomPub setContentStream
Date Wed, 09 Feb 2011 11:26:21 GMT
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 <fg@nuxeo.com> 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
> <florian.mueller@alfresco.com> 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

Mime
View raw message