chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Florian Müller <florian.muel...@alfresco.com>
Subject Re: setting filename with AtomPub setContentStream
Date Wed, 09 Feb 2011 12:32:49 GMT
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<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
>>
>
>
>


Mime
View raw message