chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Potts <>
Subject Heads up on refactoring efforts around cmislib
Date Wed, 27 Feb 2013 04:07:28 GMT
Greetings from ApacheCon in chilly Portland! I have started a couple of refactoring efforts
around cmislib I want to make sure everyone is aware of.

Replacement of most of with httplib2

All of the code that deals with actually making a request over HTTP resides in When
the library was originally written, the best approach was to leverage a Python module called
urllib2. Using this approach, custom code was added to handle POST, PUT, and DELETE, redirects,
and so on. I have started the work of replacing that with a higher-level module called httplib2.
This will reduce the amount of custom code we have to maintain and will pave the way for easier
handling of authentication methods beyond basic auth.

This work is taking place in trunk and the first round of refactoring (replacing the urllib2
classes with httplib2) is complete. The next step is to further refactor the code such that
a developer could instantiate and pass in their own httplib2.Http object which cmislib would
then re-use. This will give devs more control over how cmislib communicates with the CMIS

Isolation of binding-specific logic to a binding-specific module

Currently, the cmislib domain objects all have detailed knowledge about how to work with the
AtomPub binding. This makes adding additional bindings problematic. A better approach would
be to have those domain objects act more like interfaces, then create binding-specific modules
that know how to work with a given binding.

At a high-level, all domain objects are moving to a new file called leaving CmisClient
in for backwards compatibility. All Atom Pub specific code is moving to
The browser binding objects will live in

Now, when you instantiate a CmisClient, if no binding is specified, the CmisClient object
will instantiate and use the Atom Pub binding. However, if you want to use a different binding,
you can just pass it in when you instantiate the client. Then, when you fetch a repository,
you'll get back either an AtomPubRepository or a BrowserRepository, depending on the binding.
And so on for AtomPubDocument, AtomPubFolder, etc.

I've started doing the binding refactor work in a new branch called "binding_refactor". The
Atom Pub refactoring is done and I've started working on the browser binding.

In both cases, devs using cmislib will not need to make any changes in how they work with
the library if they want to continue to use the AtomPub binding and do not need to make any
changes to things like HTTP headers or other network details. However, it does mean that cmislib
will have a new dependency on the httplib2 module. This dependency will be resolved automatically
if the library is installed with setup tools, which is the normal/preferred approach.

If anyone has feedback on this or wants to discuss it further, let me know. Otherwise, I'll
push forward.

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