[Adium-devl] LMX plans

[Evan Schoenberg]

On Feb 24, 2007, at 2:40 AM, Peter Hosey wrote:

> 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.
Assuming it works perfectly, I'd scratch 'desperate'.  but I still  
agree that it's needed. That giant function hurts my head.  And I  
wear a helmet.  My doctor tells me it's for the best.

> 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.
Assuming it wouldn't be significantly more effort to implement or  
maintain, yes.  OTOH, I personally love me some Foundation... :)

> 3. LMX has never seen a release.
>
> I'm going to address #3 first.
Sounds like a good thing to me.
>
> ⁃ 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.
Much easier to debug. Awesome.

> ⁃ 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?

That all sounds like a good thing to me, with the possible caveat  
that I'm concerned about things being more difficult to work with  
when written in straight C.

Cheers,
Evan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20070301/fe639cf6/attachment-0001.html>
-------------- 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/20070301/fe639cf6/attachment.sig>