Hi Jeff, have you thought about using the Requests library instead ? https://github.com/kennethreitz/requests
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 ? S. 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 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 -- Stefane Fermigier, tech entrepreneur http://fermigier.com/ - http://twitter.com/sfermigier - http://www.linkedin.com/in/sfermigier "Well done is better than well said." - Benjamin Franklin "There's no such thing as can't. You always have a choice." - Ken Gor
