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 Thu, 10 Feb 2011 14:41:44 GMT
This is now committed, see CMIS-301 and
http://svn.apache.org/viewvc?view=revision&revision=1069413

I suggest that the PHP and Python implementations should generate as
well this Content-Disposition header to interoperate with
OpenCMIS-based servers.

Florent


PS: the parser code for RFC 822 headers and RFC 2231 non-ASCII
parameter encoding is inevitably a bit complex if we want to avoid
interop bugs down the line. Code taken from Geronimo.


On Wed, Feb 9, 2011 at 1:32 PM, Florian Müller
<florian.mueller@alfresco.com> wrote:
> 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
>>>
>>
>>
>>
>
>



-- 
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