Ionrock Dot Org

Recently, I've been working with a friend on a website. Part of the reason I was asked in the first place is because of my experience with Bright Content. It has been a while since I've spent a good deal of time on Bright Content, so I've been becoming reacquainted with the code. In this process of grepping and searching for answers, it has occurred to me this is entirely too much work.

Part of the thinking behind BC is to create a truly RESTful system. All the different features are meant to be servicealizable , which is simply a made up way of saying they can be used to support other systems. This in turn has required a huge helping of generic-ism in terms of design, but more importantly, it managed to explode the complexity by trying to be all things to all applications. My resolve now is to simply cut the fat.

The first thing I'm going to do is push as much work to others as possible. I had previously tried to do this through using Amplee as the basis of the store. Instead, Amplee will simply be another AtomPub endpoint that supplies a means of storage. For practical purposes, this will start with WSGI versions of the examples, but, with that said, if Sylvain continues to evolve the examples to be closer to full blown applications, I could care less that I run an extra process.

The next thing I'm going to do is experiment with other templating systems. The first one will be Mako, specifically because it is not based on XML. I'm still a fan of manipulating XML with XSLT, but I'm hoping to avoid the massive amount of XML hoops I had to jump through previously. I'd imagine I will still be transforming the feeds with XSLT, but the basic templates and functionality of adding plugins or widgets will be done with Mako and Python instead of trying to force fit everything in XSLT.

I should point out that this does not necessarily convey BCs direction as a whole as much as it sheds light on my desire to diversify a bit. When I was a kid, unless a song was hard, fast and punk, I didn't really like it. Now that I'm older, I'm a bit more pragmatic and I appreciate the desires of the masses. Too many folks have issues with XML (justified or not) where ignoring the progress of things like JSON as well as the reliance on tools like Pyro. In other words, use the best tool for the job and look for ways to better manage the myriad of tools.

Beyond the toning down of XML usage and dropping the idea of an actual XML store, the bigger goal will be to continue to support distributed systems. This blog is a decent example in that I made a few small strides to incorporate other feeds into the page. This ended up being simple to do via Javascript, but I'd like things to be easier because BC makes it easy and cacheable. The other day I was turned on to Posterous and I really like the idea. I've always thought email was a powerful protocol because the clients are well versed, and this is just another reason why. With that in mind, pulling from and pushing to services will become the backbone of BC, with AtomPub being the obvious first focus.

Even though many folks might see BC as a waste of time (another CMS!!!) it is a ton of fun. I've made some great friends and have been able to test the feasibility of RESTful designs, while learning a lot in the process. Moving forward, I'm exciting about the possibilities, but more important, I'm having a great time.