chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schmidt <peter.schm...@alfresco.com>
Subject Proposal for changes in the ObjectiveCMIS library
Date Fri, 15 Feb 2013 15:35:13 GMT
Hi all,

prior to our next developer meeting I wanted to give you a heads up of
further change proposals to the ObjectiveCMIS library.

Before doing that let's recapitulate the changes submitted to SVN so far:

   1. CMISNetworkProvider interface to override the default network request
   handling in the library with a custom network API. As a part of that the
   CMISHttpUtil.m (HttpUtil class) has been renamed to
   CMISDefaultNetworkProvider and the invoke methods have been changed to
   instance instead of class methods.
   2. Refactor some of the method signatures to reflect Apple's code
   guidance. E.g. withHttpMethod has been renamed to httpMethod.


Here is the list of further proposed:

   - All network requests are cancellable.
      - For that all invoke<XXX> methods to take a CMISRequest object. For
      clarity the parameter has been renamed from requestObject to cmisRequest
      - Typically network requests in the CMIS lib are nested calls.
      Therefore, the CMISRequest class now has an internal array to which newly
      created requests are added.
      - The CMISRequest.h file also defines a CMISCancellableRequest
      protocol with a defined method - (void)cancel in it. Classes such as
      CMISHttpRequest will implement this protocol. CMISRequest will only add a
      new cancellable request to it, if the class conforms to the
      CMISCancellableRequest protocol.
      - Most methods in CMISSession, CMISDocument, CMISFolder return a
      CMISRequest object. Exceptions are when creating a CMISSession
      (authenticate/connect). It might be a bit overkill to make that
      cancellable, too.
      - When a cancel request is issued: all requests in the array in
      CMISRequest will be cancelled - going all the way down the nested request
      structure if need be
   - changeContentToContentOfFile/OfInputStream methods: we found it is
   necessary to pass in a mimeType as well. The rationale is, that the
   mimeType cannot be deduced from the filename in all circumstances - in
   which case it may default to the wrong type.
   - further clean-up of methods and ordering of names. E.g.
   includeRelationShips was renamed to relationships (include... is used for
   BOOL values).


-- 
Kind regards
Peter

-----------
*Peter Schmidt*
*Alfresco Software Ltd.*
*UK: 07748 185496*
*Int.: 0044 7748 185496*
*Skype: pweschmidt*

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