Direction comments

[Jared Rhine <jared@xxxxxxxxxxx>]

[John == jgoerzen@xxxxxxxxxxxx on Tue, 29 Jul 2003 09:15:22 -0500]

Jared> As long as the code is monolithic, in a single process space,
Jared> and not accessible via IPC, I can't really integrate with it.

John> As you point out, it requires modules to be written in Python.
John> To me, that is not a disadvantage, but I can see how it is for
John> some.  In fact, if you don't want to use Python, it would indeed
John> seem like a big monolithic black box over there.

It does indeed look like a big monolithic black box from where I'm
sitting.

John> It would be quite easy to write a UI module that accepted
John> connections on a named pipe and shoved data down it.

Would it be as easy to plugin non-UI adaptors?  I can see applications
for which I'd want to have an event come in from somewhere (Jabber,
cron job, whatever), and use that to trigger a synchronization run for
a single folder, for instasnce.  I assume, actually, that any UI
plug-in would have pretty full access to the rest of the offlineimap
modules, so one could probably rig this up, if one wanted.

John> One side effect that Twisted can provide is that it has some
John> built in "shell-like server" capabilities.  OfflineIMAP could
John> listen on a named pipe and accept requests from whomever cares
John> to request something.

That's fairly much in the spirit of what I was talking.  Too bad I
don't have any immediate applications, or I'd offer to help with this
particular niche.

Now having finally found the twisted homepage, I do see it's very much
in the spirit of what I was thinking, a general event-handling
framework, perhaps much like the beloved Perl equivalent POE
(poe.perl.org).  Given that general framework, you have the same
"generalized access from another process space" support that you'd
need to break the "monolithic" nature I was whining about.

I'm all for the twisted route now.  Such architectures feel much like
the multi-process/fork-oriented approach I suggested, without having
to deal with all the drudgework of inter-process coordination that
makes the fork approach so scary.

John> You are probably correct that the UI could be split off using
John> IPC without too much effort or complexity, but the question
John> facing me thus far is: why bother? :-)

Primarily for reasons and applications one can't possibly imagine
ahead-of-time.

John> Would it be helpful for people if I write up a "hacking
John> OfflineIMAP" document?

Probably not for me, because as you say:

John> I think that somebody that's already a skilled programmer in
John> another language (and is familiar with TCP communications) could
John> probably get up to speed enough with Python and OfflineIMAP to
John> begin doing some basic stuff within 2-3 hours.

Give me a socket/RPC ala twisted interface and I can get up to speed
even faster.

-- jared@xxxxxxxxxxx

War is God's way of teaching Americans geography. -Ambrose Bierce