chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Hübel <jhue...@opentext.com>
Subject RE: svn commit: r1098638 - /chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java
Date Thu, 12 May 2011 15:37:05 GMT
Yes I agree totally. My question was more about what is the best way to implement getPathSegment()
on the server. You will likely not use a random number but base it some information that you
store somewhere. But as you point this is not a very useful question to ask. CMIS is driven
by exposing your existing model. And it does this job pretty well here.

Jens

-----Original Message-----
From: Florent Guillaume [mailto:fg@nuxeo.com] 
Sent: Donnerstag, 12. Mai 2011 16:34
To: dev@chemistry.apache.org
Subject: Re: svn commit: r1098638 - /chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java

The choice of having 3 different concepts (cmis:name,
cmis:contentStreamFileName and relative path segment) was deliberate
and allows various vendors to expose their internal models without
ambiguity.

If cmis:name is used for path composition then the client is simply
broken. Path composition must only be done using relative path
segments.

I know that Adobe Drive 2 is already broken in this respect, but
please let's not dumb down the spec for the benefit of bad
implementors (who in this case had advance warning during their beta
phase that their implementation was broken...).

Florent


On Tue, May 10, 2011 at 8:52 PM, Jens Hübel <jhuebel@opentext.com> wrote:
>
> This looks like needing a fix in the errata. If it is not specified.
>
> I wonder how much sense this property makes at all if cmis:name is uses for path composition
and the unique name constraint within a folder? Does anyone use contentFileName for this?
>
> -------------
> This message is sent from a mobile device.
>
>
> ----- Original Message -----
> From: Florent Guillaume <fg@nuxeo.com>
> To: dev@chemistry.apache.org <dev@chemistry.apache.org>
> Sent: Tue May 10 18:55:31 2011
> Subject: Re: svn commit: r1098638 - /chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java
>
> On Tue, May 10, 2011 at 6:15 PM, Florian Müller
> <florian.mueller@alfresco.com> wrote:
>> The spec allows cmis:contentStreamFileName to be read-write but I think it would
be inconsistent. It's probably an oversight since the Updatability is set for all properties
except for this one. It doesn't not even say it is repository specific - it's just missing.
>
> I can see a clear use case for wanting to change the filename of an
> existing document without rewriting the whole content stream. In this
> case having cmis:contentStreamFileName writable is a clear win. It's
> much less common to want to change the mime type after the fact.
>
>> The file name and the MIME type are set together with the content in the contentStream
structure when a document is created or content is updated.
>> If a client sets the file name in contentStream and sets cmis:contentStreamFileName
during document creation, which one is authoritative?
>
> Repo-specific.
>
>> cmis:contentStreamMimeType is read-only. So, why should cmis:contentStreamFileName
be read-write?
>> And the other way round: If there is a reason to make cmis:contentStreamFileName
read-write then cmis:contentStreamMimeType should also be read-write.
>
> See above.
>
>> Most repositories I have seen so far set cmis:contentStreamFileName to read-only.
>> The change is more about clarity than spec compliance.
>
> Anyway our repo is happy to allow writes to cmis:contentStreamFileName
> and as long as the OpenCMIS library doesn't prevent this use case I'm
> happy. If in-memory wants to be restrictive then why not, but I still
> don't see the point when the implementation is cheap.
>
> Florent
>
>
>>
>>
>> Florian
>>
>>
>>
>> On 10/05/2011 16:22, Jens Hübel wrote:
>>> Hmmm,
>>>
>>> looking at section 2.1.4.3.3 Property Definitions line 1357, I really don't see
that updatability is enforced as read-only.
>>>
>>> @Florian: Florian, I think you pointed out that the original implementation does
not behave correctly. Can you refer to the spec? Or did I misunderstand and changed the wrong
place?
>>>
>>> Jens
>>>
>>>
>>> -----Original Message-----
>>> From: Florent Guillaume [mailto:fg@nuxeo.com]
>>> Sent: Dienstag, 10. Mai 2011 16:37
>>> To: jens@apache.org
>>> Cc: dev@chemistry.apache.org
>>> Subject: Re: svn commit: r1098638 - /chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java
>>>
>>> Why?
>>>
>>> On Mon, May 2, 2011 at 6:04 PM,<jens@apache.org>  wrote:
>>>> Author: jens
>>>> Date: Mon May  2 16:04:49 2011
>>>> New Revision: 1098638
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1098638&view=rev
>>>> Log:
>>>> make cmis:contentStreamFileName read-only for InMemory
>>>>
>>>> Modified:
>>>>     chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java
>>>>
>>>> Modified: chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java
>>>> URL: http://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java?rev=1098638&r1=1098637&r2=1098638&view=diff
>>>> ==============================================================================
>>>> --- chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java
(original)
>>>> +++ chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/types/DocumentTypeCreationHelper.java
Mon May  2 16:04:49 2011
>>>> @@ -194,6 +194,7 @@ public class DocumentTypeCreationHelper
>>>>
>>>>          propS = PropertyCreationHelper.createStringDefinition(PropertyIds.CONTENT_STREAM_FILE_NAME,
>>>>                  "CMIS Content Stream File Name Property");
>>>> +        propS.setUpdatability(Updatability.READONLY);
>>>>          propertyDefinitions.put(propS.getId(), propS);
>>>>
>>>>          propId = PropertyCreationHelper.createIdDefinition(PropertyIds.CONTENT_STREAM_ID,
"CMIS Stream Id Property");
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
> --
> 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