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 net.py with httplib2 All of the code that deals with actually making a request over HTTP resides in net.py. 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 server. 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 domain.py leaving CmisClient in model.py for backwards compatibility. All Atom Pub specific code is moving to atompub_binding.py. The browser binding objects will live in browser_binding.py. 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. Jeff
