[Adium-devl] LMX plans

[Peter Hosey]

I've been doing some thinking about LMX lately. These are my  
thoughts, and my conclusions.

1. LMX is in desperate need of a redesign.

LMX's backwards nature is bad enough for people's heads, but LMX  
stuffs the entire parser into one hugemongous method. This creates a  
nearly-impenetrable wall of code, such that so far, Evan is the only  
one who's been able to contribute any bug fixes to it (aside from  
some from Colin early on, when the code was fresh), but even he's  
been wrong in LMX at least once, precisely because the code is so  
hard to grok.

2. A pure-C version of LMX would be useful.

Gaim, for example, could use a C version of LMX to implement message  
history as we do. Any chat client could, really, as long as it used  
XML in some flavor for its logs.

3. LMX has never seen a release.

We use LMX in Adium, yet LMX has never even been a 0.1 release. It's  
always only been a SVN revision.

Conclusions:

I'm going to address #3 first.

It's time to take a stand and say “this is 1.0”. Tomorrow  
(Saturday), I'm going to create a 1.0 branch, and if you have any  
patches in development/in a holding pattern for the Obj-C  
implementation of LMX, you're welcome to apply them there. (Please  
let me know, especially if you're going to miss the window, so I can  
extend the deadline if appropriate.)

One week later, I'll tag and release 1.0, complete with a webpage.  
The address will be <http://boredzo.org/lmx>. (I'll continue to use  
the SVN repo on adiumx.com, mainly because I haven't figured out a  
way to import a SVN dump into a repo on my shared host.)

Tomorrow, after I create the 1.0 branch, I'll start work on 2.0. This  
will be the pure-C implementation of LMX. Design points:

⁃ The parser will be broken out into subroutines. There will be a  
function for every state the parser can be in (pcdata, cdata, tag,  
attribute value, entity reference, etc.), and a series of bits/bools  
which will be checked in a specific order to determine which state  
should be dispatched to for a specific character. This will help  
debugging, since you'll know what the parser believed it was  
consuming at the time.
⁃ *No more local variables*. Everything gets stored in the parser  
structure. This is the main reason why the parser was all in that  
function: because its state was in local variables, not instance  
variables.
⁃ Some things will get their own file. For example, entity names are  
looked up using a mapping (dictionary); this code would be in  
mapping.c. (Name subject to change. I'm open to suggestions. I've  
never liked the term “dictionary”, though.)
⁃ The goal is to have something that builds on any sane system. This  
includes Mac OS X, but is not limited to it. That means pure C99,  
with as little hackery as possible. However, platform-specific code  
will be allowed providing it is properly sectioned off (e.g.  
mapping.c will be implemented using CFDictionary for OS X).
⁃ There will be an Obj-C wrapper in a framework.
⁃ Hopefully, the Obj-C API will remain unchanged from 1.0. I'll try  
to keep the changes as minimal as I can, in any case.
⁃ Build system: make. Supporting platform-specific code will require  
detection of certain platforms, so I'll write a basic configure  
script in Python. (I don't like autoconf. It scares me.)
⁃ The framework will be built using xcodebuild (similarly to how  
Adium's makefile works, except that Adium doesn't *require* you to  
use make to build it).

Questions? Suggestions?

________________________________
\ Peter Hosey / prh at boredzo.org
PGP public key ID: C6550423 (since 2007-01-01)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070223/8c7e382b/attachment.sig>