Uploaded image for project: 'OASIS Content Management Interoperability Services (CMIS) TC'
  1. OASIS Content Management Interoperability Services (CMIS) TC
  2. CMIS-135

createDocument & checkIn - Accept an optional contentStream input. How is this included and encoded?

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Domain Model, REST/AtomPub Binding
    • Labels:
      None
    • Proposal:
      Hide

      In light of the atomic create/update issue, we should probably keep the stream as input to these two methods.

      Show
      In light of the atomic create/update issue, we should probably keep the stream as input to these two methods.
    • Resolution:
      Hide

      We will clarify in the protocols how the content stream should be encoded when provided in the create/checkin messages.

      We will NOT add an option to retrieve the encoded content stream as part of getProperties, because it would be really inefficient. (It's equally inefficient on create, but in those cases we have an explicit requirement for including them to ensure compatibility with some existing repository limitations.)

      Show
      We will clarify in the protocols how the content stream should be encoded when provided in the create/checkin messages. We will NOT add an option to retrieve the encoded content stream as part of getProperties, because it would be really inefficient. (It's equally inefficient on create, but in those cases we have an explicit requirement for including them to ensure compatibility with some existing repository limitations.)

      Description

      Sections: 3.4.1 & 3.7.3

      1) Is this really necessary, as there is an entire set of stream services?

      2) The schema (CMIS-Core) includes a type (cmisContentStreamType) but it is not referenced anywhere else except in CMIS-Messaging (which appears to be SOAP-related). How might this stream be incorporated into an Atom Entry (for REST) - is it Multi-Part?

      3) It seems reasonable that a stream be provided to aid in atomic creates/updates.

      4) If streams really are expected to be large enough to merit a sub-range requirement on getContentStream (see 3.4.7), then is it realistic to expect that one would base64 encode such a beast?

      5) If the Entry document schema is modified to accept an encoded stream (or the spec clarified as to where this is placed within the Entry), then why would that stream also not be available from getProperties? This leads to an asymmetrical usage of streams.

      6) For large streams where encoding is not practical, there should be a way to (for example) create a document which requires a stream, set that stream in a separate operation, and then commit/checkin that change (at which time the "required stream" is enforced).

        Attachments

          Activity

            People

            • Assignee:
              ethang Ethan Gur-esh
              Reporter:
              ryan.mcveigh Ryan McVeigh (Inactive)
            • Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: