August 07, 2002

Wish list for a Weblog tool

Cocoon | Weblogs

I've been using MT for more than a week now, and I started to feel some of its limitations. Here's a small wish list for it, or for any other Weblog tool. In particular, I got prompted by Ugo Cei's message on cocoon-dev, to think about working on Cocoblog as the tool to use for my Weblog.

Here is the list:

  • As with MT, and unlike Radio, the Weblog tool should reside on the Web site only. No installation on the user's desktop should be required, other than perhaps a simple Weblog editor which communicates over XML-RPC with the server. In my case, this editor would have to be XEmacs, of course. Other free software/open source tools are available as well.
  • The Weblog tool should have the notion of multiple users or authors, each managing one or more weblogs. It should allow multiple users to author the same weblog.
  • The system should have the notion of an administrator, which manages the permissions of users. The administrator should not be an user.
  • As with MT, the system should generate static HTML pages for the Weblog reader. Dynamically generating HTML pages would quickly become a problem when the system is deployed within limited resources available, such as those imposed by cheaper accounts at various ISPs. The management interface for the Weblog author would have to be dynamic though, to permit the management of the Weblog.
  • The system should provide two views of the generated Weblog. One view should be public, accessible to external viewers. The other view should be visible to the Weblog author only, and it will allow him/her to customize the look and feel of the site without afecting the public view. Once the author is happy with the look and feel of the private view, this could be published as the public view.

    With MT you get only one view, the public view. Each time you want to change something in the Weblog look, the changes become immediately visible to the public, which is not a good thing. Of course, you can setup a private area which uses the same data, but that's an administrative headache which could be avoided.

  • The system should have the ability to run periodic tasks on behalf of the user. This could be used to run blogroll scripts, calendar updates or any other action which causes the static HTML regeneration to happen.
  • It should be possible to edit Weblog entries in languages other than XHTML. I specifically have in mind the ability to edit entries using Docbook, xdocs or any other custom built XML format. This would give the ability to easily change the generated HTML markup or to generate entirely different markup, like plain text or XSL-FO for PDF generation.
  • The user should have the posibility of specifying custom XSLT stylesheets for different markup generation. The system should also allow arbitrary XML processing to happen on the original markup.
  • With the ability to edit Weblog entries in an XML format, a dictionary of abbreviations could be easily defined. This could be implemented either as XML entities or as XML elements which are translated to their definition by custom XSLT stylesheets.
  • The system should be written using components which plugin into the system easily. Ideally, it should be easy to write such components using any scripting language.
  • The system should have a clearly defined internal API, which exposes all the major items in it: entries, categories, stories, components etc. These internals should be exposed to all the scripting languages supported. Components written in different languages should be able to inter-communicate.
  • New components should be easily added to the system. However this task should be under the control of the administrator, which could install these components and make them available to users, perhaps in a selective, per-user maner, to permit a pay-per-use model.

In my opinion, Cocoon can solve most of these problems. One thing it badly misses is the ability to easily add new components to the system, and make them available in a selective manner, and the ability to have these components written in different scripting languages.

Posted by ovidiu at August 07, 2002 10:20 PM |
 
Copyright © 2002-2016 Ovidiu Predescu.