You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Florent Guillaume <fg...@nuxeo.com> on 2011/02/08 17:03:37 UTC
setting filename with AtomPub setContentStream
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
Re: setting filename with AtomPub setContentStream
Posted by Florian Müller <fl...@alfresco.com>.
Hi Florent,
I have totally missed RFC 2231. That makes the implementation really
complex ... thanks for doing it.
I will add the Content-Disposition header to DotCMIS soon.
Cheers,
Florian
On 10/02/2011 14:41, Florent Guillaume wrote:
> 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
> <fl...@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
>>>> <fl...@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
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: setting filename with AtomPub setContentStream
Posted by Florent Guillaume <fg...@nuxeo.com>.
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
<fl...@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
>>> <fl...@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
Re: setting filename with AtomPub setContentStream
Posted by Florian Müller <fl...@alfresco.com>.
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
>> <fl...@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
>>
>
>
>
Re: setting filename with AtomPub setContentStream
Posted by Florent Guillaume <fg...@nuxeo.com>.
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
> <fl...@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
Re: setting filename with AtomPub setContentStream
Posted by Florent Guillaume <fg...@nuxeo.com>.
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
<fl...@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
Re: setting filename with AtomPub setContentStream
Posted by Florian Müller <fl...@alfresco.com>.
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
>