chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefane Fermigier>
Subject Re: Heads up on refactoring efforts around cmislib
Date Wed, 27 Feb 2013 11:55:46 GMT
Hi Jeff, 

have you thought about using the Requests library instead ?

Same for XML parsing, instead of parsing XML using low-level libraries, have you though about
using something higher-level ? Last summer, I've experimented a bit with a CMIS parser using
lxml.objectify for deserializing the XML payload.

Also, it's good to know you're working on the browser binding.

Have you given any thought to the idea of decoupling things a bit further so as to allow people
to use cmislib to implement servers, as well as clients ?


On Feb 27, 2013, at 5:07 AM, Jeff Potts wrote:

> 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 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 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
> If anyone has feedback on this or wants to discuss it further, let me know. Otherwise,
I'll push forward.
> Jeff

Stefane Fermigier, tech entrepreneur - -
"Well done is better than well said." - Benjamin Franklin
"There's no such thing as can't. You always have a choice." - Ken Gor

View raw message