R.A.W.: The future of PyBlosxom

The future of PyBlosxom · 14. October 2004, 00:28

This is the first in what I hope to be a series of articles covering my ideas for the future development of PyBlosxom.

The ideas presented here are a very mixed bag. I’m sure I’ve left ideas off this list and hopefully I’ve added in a couple that people may not have thought about before. Ultimately I’ll take ideas I present here along with any feedback I get (if any) and distill it into pieces on to the devel list. The ideas also do not include general clean up and documentation that is required inside the current PyBlosxom code – this is an ongoing requirement.

I am also more interested in seeing implementations of some of the ideas more than others. I have no intention of implementing them all. I will however work on those that are of use to me. Anyone and everyone can certainly feel free to tackle any problem listed here – I do not demand exclusivity on any of the work! My own goals can be summed up by saying that I’d like to see more flexibility with PyBlosxom in entry storage and content management in the presence of potentially large numbers of entries.

Outline of ideas for PyBlosxom – future articles will expand on each of these items:

Running pyblosxom under mod_python etc. Can WSGI be of use here? Ian Bicking has just written a timely article on the state of WSGI implementations. His parting comment is:

Really the next step is to get some more frameworks ported.

This sounds like PyBlosxom is indeed a candidate for using the WSGI.
Implement a sort callback system to allow sorting of entries other than by date.
Use the BunchDict recipe for configuration. This is a cleaner interface for accessing configuration variables in my opinion. I’d also like to see the the entry metadata computed in a lazier, “need to know fashion” – this would help improve speed even more and would make the implementation of a sort callback easier and more efficient (only the metadata required for sorting will actually be computed).
Clean up entry system – make it even easier to use/plugin alternative storage types – in particular enable storage to a database.
Web front end. This weblog does not use PyBlosxom (it uses Textpattern. The main reason for this choice is the availablility of an excellent content management interface. I would like to see hooks in the core pyblosxom code to support this also (i.e. PyBlosxom core would still comprise a working minimalist system like today but with the easy possibility to “drop in” a web interface). Can the Atom publication protocols be of use here?
I’d like to see the handling of dates in the path cleaned up and improved. In particular dates should use digits to represent the month by default.
Improved template system. Like blosxom allow templates to be written in a single page.
Write a Cheetah template renderer (this is something I’ve already begun to look at). This can be used for rendering complex entry types.
Dedicated syndication feed renderers (RSS2, Atom etc.)
Better search integration – I’ve few ideas on this but it would be good to have.

What do you think? Do you have other ideas and directions you’d like to see implemented in PyBlosxom?

* * *