Title photo
Ode is simple! (Simple means that you know how it works.)

Hi and welcome to ode-is-simple.com. Glad you stopped by.

There is a new Ode forum at ode-is-simple.com/vanilla2_forum

It's empty (or just about) at the moment but I've prepared several categories. Please feel free to register and participate.

Though I plan on very actively pushing content to this site, and the weblog at news.ode-is-simple.com, the forum is intended to be a community effort, as well as a resource.

Posts

Wed, 11 Feb 2009

Simple enhancements

Ode implements an addin architecture. Addins are modules that extend or redefine how Ode operates. You may be familiar with other projects where this same sort of thing is referred to as an extension, module, addon, plugin, etc.

I chose the term addin because

  1. 'add in' describes more accurately than the other terms how modules work with Ode, i.e. simply add them to your installation and you're done. The term 'addon' seems a little disparaging, as if the modules are of lesser importance. Moreover, because it's possible to replace core routines included in the script itself and not just 'add on' new functionality addon seems not entirely accurate.

  2. addin is not as commonly used as some of the other terms. So it is less likely that references to Ode addins in documentation or tutorials will be confused with something else, for example Perl or Apache 'modules'.

Essentially addins allow anyone familiar with Perl and Ode to redefine just about any aspect of the script (by redefining key subroutines) or extend the functionality of Ode in an infinite number of ways by introducing entirely new routines (more on developement later).

To install an addin simply download and copy it to Ode's addins directory. Each addin is completely self-contained. No need to worry about becoming confused over which what goes where.

These individual addin directories are referred to as bundles.

Is there anything that makes Ode's addins simple? I'm glad you asked.

Addins are managed by directly manipulating corresponding files via the filesystem, in much the same way as posts.

Interacting with the addin files directly avoids the problems and confusion that can result from using a web form that deals with the state of addins on your behalf.

For example,

With Ode you will deal with addins in exactly the same way whether everything is running smoothly or you're having trouble.

With many other packages if a module malfunctions you may lose control over it from the administration interface, or what's worse a malfunctioning or misconfigured module may prevent the software from running at all, which means that you cannot access the admin interface, and in turn cannot fix or remove the problem module. Or at least you can't do these things in the way that you would normally manage the software.

With Ode you specify an absolute order in which installed addins are run. This simplifies interaction among addins and puts you in control. After all, no one else has exactly the same installation that you do.

Modules can be disabled without being moved or uninstalled.

Addins are disabled by appending a trailing underscore to the bundle name. The advantage here is that it's possible to see at a glance whether a module is enabled or disabled.

Disabled modules do not affect the behavior of Ode and do not impact performance.

Without talking too much about development here, I do want to make a couple of points about the philosophy of addin development under Ode.

Addins should be self-sufficient with a minimum of dependencies.

External dependencis are problematic because they add to the minimum requirements necessary to use the software, and while adding one or another library may not be a problem for some installations it may be very nearly impossible for others. Furthermore, external dependencies complicate installation, configuration, and documentation.

Internal dependencies among addins should also be avoided. Things get tricky when, as an end-user, I can install the module I want but not some other module it requires because of a conflict.

In the interest of minimizing internal dependencies, addins should be single purpose.

If, as an end user, I'm installing a module to pick up one feature, it can complicate things for me if a bunch of other (unwanted) routines come along for the ride.

Small, single purpose modules should mean faster, more reliable development and finer granularity of control for the end user over what's running on her site.

All addins should be made available here at ode-is-simple.com.

This means that we won't need to worry about hunting for these things all over the internet.

Let me qualify that, of course developers are free to create addins only for themselves or put them up at their own site rather than submitting them to ode-is-simple. But, in order to keep things simple (and safe), addins which are not submitted to and downloaded from ode-is-simple.com are considered outside of the scope of the project.

Obviously, all developers are encouraged to submit their addins.

The following addins are available with Ode immediately:

Indexette - indexes posts so that Ode doesn't need to completely traverse its content directory with every request. Instead, Ode discovers posts by examining the index.

Additionally, Indexette allows new posts to be included without rebuilding the entire index.

Finally, Indexette helps to preserve the creation dates for posts. This is an important aspect of the addin. Without Indexette Ode considers the modification time of the file to be the post date. The trouble with this arrangement is that modification times may be updated when posts are edited and may change as a result of other actions. These 'other actions' are not always predictable or consistent from one installation to another (depending on various factors).

Indexette adds a tag to each post with the original modification time when the post is created. Post dates can be updated by manually changing the date and time recorded in the tag or by deleting the tag altogether (which causes indexette to add a new tag corresponding to the current modification time).

Taking this a step further, Indexette can be made to keep the modification time of the files in sync with the post date as recorded in the tag. This makes it possible to disable the Indexette addin without affecting the post dates or migrate posts to some other platform with the original modification times intact.

Everyone is encouraged to use Indexette.

Editedit - Pronounced 'Edited it', Editedit, in combination with the included edit theme allows posts to be added and updated using only a web browser.

The bundled edit theme includes a live preview of the post that understands Markdown (based on Showdown, a Javascript implementation). In other words, as you edit the text of the post, the addin provides a formatted preview.

Additionally, you can inspect the corresponding HTML markup and the previous revision of your post.

Editedit includes a basic password mechanism but because the password is transmitted as plain-text you should not use Editedit without taking additional security measures (more on security later).

Editedit is very convenient, but don't forget about your editor! Also, please be careful when posting this way because Editedit does not (yet) autosave. If you navigate away from the page while you are editing a post, close your browser window, or if your your browser or operating system malfunctions, you may lose any unsaved changes.

To be safe, if you want to use the web form and you have a long post, use a text editor and copy and paste the finished post to the Editedit form.

Markdown - Markdown has already been dicussed (see Simple Writing). The Markdown addin is nothing more than a wrapper around the Markdown script itself.

Exscape - Allows you to define various escape sequences, for example replacing special characters with corresponding HTML entity references. Keep in mind that some of this is handled by Markdown (See the Markdown syntax reference for more information about how Markdown handles escape sequences).

Many more addins are on the way. I'll shortly post a list of the addins I'm working on and invite other developers to do the same, i.e. start working on new addins and post a list of addins they're working on and a 'best-estimate' timeframe so that other developers and end-users can anticipate work that is being done related to the project.

Note that Ode does not use a package manager (like CPAN). Why? Doing so adds an external dependency, potentially fractures support and maintenance issues between multiple projects, and complicates initial setup and configuration, especially for users new to both Ode and the package manager who must, at the outset, contend with multiple new projects.

Next (Simple upgrades)