Direction comments

[Jared Rhine <jared@xxxxxxxxxxx>]

[John == jgoerzen@xxxxxxxxxxxx on Fri, 25 Jul 2003 21:23:22 -0500]

>> 2. Switch to a multi-process model using IPC.  Ala postfix or
>> qmail.

John> That's something I had considered, too; however, I don't think
John> it would work so well for us because the model here is not quite
John> so easily broken up into that sort of bite-sized chunk.

I wouldn't have thought that some other apps could be broken into a
multi-process model effectively, either, but they did it successfully.
I bet it could be done, but I'm not offering to do it, either.  You've
spent about 10^6 times more thinking about the problem space than I,
so I'm sure your judgment here is sound.

John> It doesn't magically solve the threading problem either; they
John> use fork(), I use clone()...

Ok; it sounded like you were encountering bugs in the thread-specific
support in python, in which case switching to fork would actually
solve those specific issues, I figured.

John> ...threading and fork() mix rather poorly I've seen.

Yes, indeed.  As mentioned, switching to fork would be a big deal and
major commitment.  With only fuzzy benefits.  Not a good option,
especially if you've found better options, like whatever that Twisted
thingy is. 

>> 3. Break the GUI out of the main codebase.

John> OK, but I use it, so I'll be maintaing it anyway, and it's more
John> work to split it out.

Yes, more work, but having it integrated, monolithic, and in the same
codebase is a sign (to my humble eyes) of an architectural issue which
limits extension.  My suggestion is essentially to get it out of the
same process space.  But the benefits would only be architectural, not
functional.  In the mean time, I can't hack my own interface unless I
code python.  Not a big limitation, I'll grant.

>> 4. Lower expectations of additional coding help.

John> I'm fine with it if I remain the person doing most of the work.
John> I think it would be better if there are more people working on
John> it, and I want to encourage people to do so because I think it
John> will make OfflineIMAP better.  But I'm fine if nobody else wants
John> to.

Well, maybe I'd like to help, but I'm not going to learn python just
to help out.  As long as the code is monolithic, in a single process
space, and not accessible via IPC, I can't really integrate with it.
If it was IPC/socket/whatever based, I could throw together other UIs
or extensions via my preferred mechanisms.  Not that I actually have
any need to do so.

Regardless of any of the above musings, I'm very happy with the
codebase and your maintainership as it is.  My trust continues to grow
and I believe I'll be pleased no matter what direction you take the
project.

-- jared@xxxxxxxxxxx

"Better to be of a rare breed than a long line." -- TDK