You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Jake Karnes <jk...@ziaconsulting.com> on 2018/03/06 17:08:09 UTC
No Content Stream vs. Empty Content Stream
Hello,
I'm looking to better understand how to handle the difference between a
cmis:document having no content stream, and a content stream that is empty
(0 bytes). This scenario is handled differently by the example CMIS
servers, and I'd like to understand which is correct.
The example in-memory server tracks a document's content by
maintaining a ContentStream
(fContent
<https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/storedobj/impl/DocumentImpl.java?view=markup#l39>
) for each Document. If the document has no content stream, then fContent
is null. If the document has a content stream, fContent is a
ContentStreamDataImpl
<https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/storedobj/impl/ContentStreamDataImpl.java?view=markup>
object
which may have 0 or more bytes of underlying data. Whether fContent is null
or is a populated ContentStream object, it is returned by the
getContentStream service.
The in-memory server handles no content stream differently than an empty
content stream. This matches the TCK test testAppendStream
<https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-test/chemistry-opencmis-test-tck/src/main/java/org/apache/chemistry/opencmis/tck/tests/crud/SetAndDeleteContentTest.java?view=markup#l220>
which starts by creating a document with empty content. The test ensures
that a non-null ContentStream is returned after the document is created,
and that ContentStream must be empty (0 bytes).
The fileshare example server does not differentiate between no content
stream and a file having 0 bytes of content. In its getContentStream
implementation
<https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-fileshare/src/main/java/org/apache/chemistry/opencmis/fileshare/FileShareRepository.java?view=markup#l1128>,
it throws a CmisConstraintException if the file has 0 bytes (per the
specification
<http://docs.oasis-open.org/cmis/CMIS/v1.1/errata01/os/CMIS-v1.1-errata01-os-complete.html#x1-26500011>).
This causes the testAppendStream to fail, because it expects an empty
content stream. If the getContentStream service returned an empty
ContentStream instead, this would cause the CreateDocumentWithNoContent
<https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-test/chemistry-opencmis-test-tck/src/main/java/org/apache/chemistry/opencmis/tck/tests/crud/CreateDocumentWithoutContent.java?revision=1389521&view=markup#l90>
test to fail, because the browser binding will add a filename "content"
<https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-bindings/src/main/java/org/apache/chemistry/opencmis/server/impl/browser/ObjectService.java?view=markup#l800>
if the returned ContentStream has no filename set.
So I'm not really sure where the problem lies. If we consider that the
in-memory server's functionality is correct, then the fileshare server
should have CapabilityContentStreamUpdates.NONE. The fileshare server can't
know if a file has 0 bytes or no content stream. If this distinction isn't
important, then tests shouldn't enforce this difference. Also, the behavior
of the browser binding is different than other bindings, but I don't know
if that's an issue.
Please let me know what you think. I'd be happy to help with code changes
(if needed). Also please let me know if there is a more effective way to
communicate this information because this is my first time using the Apache
dev mailing lists.
Thanks,
Jake Karnes
ECM Consultant
Zia Consulting
m: 408.314.7075
5525 Central Avenue, Suite 200
Boulder, CO 80301
www.ziaconsulting.com
Re: No Content Stream vs. Empty Content Stream
Posted by jk...@ziaconsulting.com,
jk...@ziaconsulting.com.
Thanks for the clear response Florian. That confirms my understanding.
To be fully compliant with the capabilityContentStreamUpdatability, an implementing system would need to handle "no content" and "content with 0 bytes" differently. Alternatively, the system could advertise that it doesn't support that capability, and setContentStream, appendContentStream and deleteContentStream services would not be needed. Does that sound right?
It sounds like the FileShare implementation achieves its goal of being an easy to understand implementation, even if it's not perfectly compliant with the specification.
- Jake Karnes
On 2018/03/09 10:08:39, Florian Müller <fm...@apache.org> wrote:
> Hi Jake,
>
> The Chemistry dev list is the right place to ask.
>
> CMIS makes a clear distinction between "no content" and "content with 0
> bytes". On a file system, there is no difference between the two. When a
> document is created, an empty file is created. The information if there
> was no content stream or an empty content stream is lost. When
> getContentStream() is called, the FileShare server has to make a choice,
> which can be wrong.
> Please note, that the FileShare implementation is a very naïve
> implementation and its main purpose is to provide some sample code. In a
> productive implementation, you would record whether there was a content
> stream or not and based on that return an error or an empty content.
>
>
> - Florian
>
Re: No Content Stream vs. Empty Content Stream
Posted by Florian Müller <fm...@apache.org>.
Hi Jake,
The Chemistry dev list is the right place to ask.
CMIS makes a clear distinction between "no content" and "content with 0
bytes". On a file system, there is no difference between the two. When a
document is created, an empty file is created. The information if there
was no content stream or an empty content stream is lost. When
getContentStream() is called, the FileShare server has to make a choice,
which can be wrong.
Please note, that the FileShare implementation is a very naïve
implementation and its main purpose is to provide some sample code. In a
productive implementation, you would record whether there was a content
stream or not and based on that return an error or an empty content.
- Florian
> Hello,
>
> I'm looking to better understand how to handle the difference between a
> cmis:document having no content stream, and a content stream that is
> empty
> (0 bytes). This scenario is handled differently by the example CMIS
> servers, and I'd like to understand which is correct.
>
> The example in-memory server tracks a document's content by
> maintaining a ContentStream
> (fContent
> <https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/storedobj/impl/DocumentImpl.java?view=markup#l39>
> ) for each Document. If the document has no content stream, then
> fContent
> is null. If the document has a content stream, fContent is a
> ContentStreamDataImpl
> <https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-inmemory/src/main/java/org/apache/chemistry/opencmis/inmemory/storedobj/impl/ContentStreamDataImpl.java?view=markup>
> object
> which may have 0 or more bytes of underlying data. Whether fContent is
> null
> or is a populated ContentStream object, it is returned by the
> getContentStream service.
>
> The in-memory server handles no content stream differently than an
> empty
> content stream. This matches the TCK test testAppendStream
> <https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-test/chemistry-opencmis-test-tck/src/main/java/org/apache/chemistry/opencmis/tck/tests/crud/SetAndDeleteContentTest.java?view=markup#l220>
> which starts by creating a document with empty content. The test
> ensures
> that a non-null ContentStream is returned after the document is
> created,
> and that ContentStream must be empty (0 bytes).
>
> The fileshare example server does not differentiate between no content
> stream and a file having 0 bytes of content. In its getContentStream
> implementation
> <https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-fileshare/src/main/java/org/apache/chemistry/opencmis/fileshare/FileShareRepository.java?view=markup#l1128>,
> it throws a CmisConstraintException if the file has 0 bytes (per the
> specification
> <http://docs.oasis-open.org/cmis/CMIS/v1.1/errata01/os/CMIS-v1.1-errata01-os-complete.html#x1-26500011>).
> This causes the testAppendStream to fail, because it expects an empty
> content stream. If the getContentStream service returned an empty
> ContentStream instead, this would cause the CreateDocumentWithNoContent
> <https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-test/chemistry-opencmis-test-tck/src/main/java/org/apache/chemistry/opencmis/tck/tests/crud/CreateDocumentWithoutContent.java?revision=1389521&view=markup#l90>
> test to fail, because the browser binding will add a filename "content"
> <https://svn.apache.org/viewvc/chemistry/opencmis/trunk/chemistry-opencmis-server/chemistry-opencmis-server-bindings/src/main/java/org/apache/chemistry/opencmis/server/impl/browser/ObjectService.java?view=markup#l800>
> if the returned ContentStream has no filename set.
>
> So I'm not really sure where the problem lies. If we consider that the
> in-memory server's functionality is correct, then the fileshare server
> should have CapabilityContentStreamUpdates.NONE. The fileshare server
> can't
> know if a file has 0 bytes or no content stream. If this distinction
> isn't
> important, then tests shouldn't enforce this difference. Also, the
> behavior
> of the browser binding is different than other bindings, but I don't
> know
> if that's an issue.
>
> Please let me know what you think. I'd be happy to help with code
> changes
> (if needed). Also please let me know if there is a more effective way
> to
> communicate this information because this is my first time using the
> Apache
> dev mailing lists.
>
> Thanks,
>
> Jake Karnes
>
> ECM Consultant
>
> Zia Consulting
>
> m: 408.314.7075
>
> 5525 Central Avenue, Suite 200
>
> Boulder, CO 80301
>
> www.ziaconsulting.com