chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jake Karnes <jkar...@ziaconsulting.com>
Subject No Content Stream vs. Empty Content Stream
Date Tue, 06 Mar 2018 17:08:09 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message