Ionrock Dot Org

Recently I have been working on Bright Content and my APP client quite a bit. It has been a lot of fun getting a bunch of smaller bug fixes done and work towards a real deal release. It has also been an exercise in patience as I have had to pay attention to a great deal of detail and resolve problems that I thought were already handled. This is all part of software development of course, but since I consider myself rather new to the field (even though have been doing it a while now) learning, and more importantly experiencing, these types of scenarios has been a great process.

Bright Content has taken some great strides to become more concise and extensible. Bright Content was severely lacking a second store implementation, which in turn made the current store API rather untested. In a desire to get a potentially faster implementation, a sqlite version came about. I found that the writes were slower so I am sticking with the flatfile store, but result is a better API improved through two decorators. The problem I kept running into was that BC takes the stance that all links are absolute. This meant we were storing the full URL for each atom:link in the store. The problem with this approach was that we were missing an abstraction between the store providing storage and some other piece placing the resulting entry in context with the actual instance of BC that was running. This also brought forth another important realization that the atom:id was not very important when working with entries. What is important are the atom:links. Again, I think I might just be slow to the party on this one as APP is clearly meant to provide functionality through hyperlinks, but it was still good to figure it out myself.

But back to the store...

So in order to provide a facility for getting entries from the store and place them in the correct context I decided I needed a filter of some kind. I first thought of making a wrapper, but that seemed somewhat overkill b/c the API really just consists of a "get_entries" method and an index attribute. The result then was to create a decorator for the getter method and a decorator for the create method, which makes the links relative. I also made the lookups based on the links since translating the URL to some atom:id format was a huge hassle. This made importing simple and easy as well as took the guess work out of finding an entry. 

Another bit I added was a CherryPy based server. I did this as CherryPy is very simple to deploy via mod_proxy and apache and it includes a bunch of helpful tools that are little more mature than Paste. I think my pattern for development then is to develop with a config file and Paste, and deploy on a site with mod_proxy and CherryPy. This allows me to use all the great middleware of Paste with the stability and maturity of CherryPy. Overall, this has been very nice and seems to use the best bits of each tool.

On the APP client front, I have been focusing on making everything stable and setting some healthy constraints. My client is specifically tailored for blogging at this point and I don't believe that will change. I might try to make the underlying APP client library a bit more robust but since APP is so simple to implement from the client perspective I am not sure. I suppose if I make sure my node copying for updates is great then that piece is probably helpful for a generic APP client, but we'll see.

One major addition is logging in via OpenID and enabling accessing documents in XSLT using authentication. The OpenID piece ended up being rather easy as I pretty much just copied the example from the Python openid module. I tweaked it a bit, but I will be going back over it in order to make a slightly more generic OpenID Auth tool that can be used as middleware (like it is now) or a decorator. Along these same lines I am also getting a similar Digest tool together built on paste.auth that I will be using for Bright Content for PUTs and POSTs. The XSLT side of things is pretty simple in that I wrapped a bit of httplib2 so I could load documents via HTTP that require authentication. I would have liked to load them closer to how the actual document function works, but in thinking about it, that would have been limiting. Now I simply return the string and create node-sets as needed via the great 4suite xpath extensions.

All in all I have been learning a ton of new things and generally getting a good understanding of rather lower level details. It is amazing to me how much more you can accomplish when you just take the time to understand the underlying protocol. Computers really are simple things when it gets down to it, so understanding something like HTTP is not much work and the benefits are huge. I hope I can continue the exploration and start getting into other things like RDF and more semantic endeavors.

Permalink | Comments