I am working on finishing up Habari’s WordPress importing facilities. This is the middle step in a long chain of personal development that is probably being done somewhat out of order, just because some things need to be complete sooner than the things they depend on.
For example, I need to have a working body of sample posts to test any work I do on a database independent library for Habari. Habari is database independent now, but we’re intent on building an abstraction class so that you can plug in new databases as needed instead of having to code any database-specific stuff directly into the core. In all, it’s a good idea. So I need test data.
Also, some folks have suggested that there will be more incentive to make things work better if I’m forced to use the software. Personally, I’d be happy to use Habari for Asymptomatic, but there is one problem… Getting my old blog data into the system.
The current Habari importer is functional, if a bit unpolished. The problem is, as exists with every import and export procedure that I’ve looked at, my database is too large. Yes, I’ve been blogging regularly since 1999. My compressed database dump for Asymptomatic is 15MB. WordPress’ export tries to dump the whole thing at once. That doesn’t work. The current Habari importer tries to import the data all at once. That doesn’t work. So I need something a little more functional.
Also, it would be nice if I could clean up the implementation while I’m poking around in there. For one, it would be cool if other importers could be written to import from other blogging tools so that other people could try out Habari.
A brief aside – like most things in Habari, the importers are classes. Actually, Importers are classes that extend the Plugin class. Plugins in Habari are basically classes that extend the base Plugin class. By naming the class members in the plugin with specific names, those functions are called at the appropriate points in the code execution to return plugin information to the core or output as required. Importers have the additional requirement in that they must implement the Importer interface. By doing so, they declare that they implement specific functions that are used by the system for importing. It’s a way for the system to use language constructs to enforce that an import plugin contains all of the functions it requires to function properly.
Yes, it’s all programmer-speak, but it boils down to this: Cool.
Anyway, to build the import system, I’ve been using some new-ish PHP editing tools to gain the benefit of a debugger. I’ve got a whole separate post cooking about the comparison of the editors I’ve tried, but I’ll reveal that I’m using PHPEdit for development and debugging.
I’ve been adding software to my system to be able to have the proper tools for development. As a result, sifting through my Start menu is a pain in the butt. I’ve been using Colibri to avoid touching my Start menu, but there are some things that I wish it could do. I long for software like Enso, but with the scriptable feature they say is waiting in the future, and perhaps not in Python.
So…
I started up Delphi and installed a few components. And in about two days, I have a working prototype, which I call Ozone. It looks vaguely like Enso. It uses Windows+space as a system hotkey instead of that stupid “hold down capslock” idea. It uses a SQL-capable database to keep track of commands. It is scriptable in Delphiscript (and possilby VB script in the future). It can display interactive HTML output in a floating window, which is useful for showing command results that do not actually run programs. It can track the currently running processes so that you can start a batch of applications (start a development environment) with one command. It can record keystrokes and mouse events for playback on a command execution.
A couple of things left to do: Track changes in the Start menu directory so that programs are automatically detected when added or changed. Improve autocomplete to produce filenames that are most frequently executed.
The scripting will eventually allow you do add todo entries to a list, then display the entries. Each of these things will be accessible by pressing a keystroke and typing a command. Adding some timer features could allow the program to display some alarms, which would be handy. All of these things could be as custom as the script that is applied to the command allows.
But it’s not quite done yet.
So it’s convenient to blame the delay of Habari releases on the fact that I can’t launch programs by typing their name after a single keystroke, even if that’s not entirely the case. But I’m looking forward to the functionality that my little (under 1MB in two files, including the database) Ozone program provides, and hope that it’s useful to others if I release it soon.
