Subject: Object-oriented IMAP/c-client implementation?

From: [email-masked] (William Chung)
Date: Fri, 21 Jul 1995 16:19:20 -0400

There were some murmurs a while back about people working on object-oriented
implementations for an IMAP toolkit.  Does anyone have any information about
the current status of an OO implementation of c-client or any other OO IMAP
toolkit?  Please include me in any response since I'm not subscribed to
the c-client list.

Thanks,
- William Chung.
Multimedia Messaging
IBM Research, Hawthorne, NY
[email-masked]

---

From: Mark Crispin <[email-masked]>
Date: Fri, 21 Jul 1995 13:23:17 -0700 (PDT)

> toolkit?  Please include me in any response since I'm not subscribed to

I don't have a specific answer for your question, but I do have a comment:

I don't see why an OO implementation of c-client is particularly valuable or
useful, unless it's to satisfy some emotional need (which may appear as a
checklist item in some design specification).  Technically, when you remove
the considerable OO is just a programming methodology, intended to compel a
particular programming discipline that can be lacking in purely procedural
code.

However, c-client already has that discipline.  Each mail storage driver is in
effect an object class (that in turn is a subclass of the overall mail class);
a MAILSTREAM is in effect an object.

It is quite straightforward to write a jacket to c-client in C++, Obj-C,
SmallTalk, Lisp, etc. that provides a native OO interface in these languages.
I'm not a C++ expert, but in Obj-C, SmallTalk, and Lisp the code to do so
would consist mostly of declarations and one-line definitions.

This also leads one to wonder whether you really need the jacket at all!  For
example, my MailManager application in NEXTSTEP was written in Obj-C, but
called c-client routines directly.  Making c-client structs be separate
objects and c-client calls be separate classes and methods would have just
added a layer of overhead.  Typically, a MAILSTREAM ended up being saved in an
instance variable on a class that had a lot of interface details (which can't
be in c-client!) so it really made no difference whether I did:
  [curWindow settext:mail_fetchtext ([curWindow stream],[curWindow msgno])];
or
  [curWindow settext:([curWindow folder] fetchText:[curWindow msgno])];
other than adding extra levels of indirection.

The only other advantage of an OO language is that they generally have far
superior memory management to C; instead of malloc() and free(), you create a
chunk of memory (or a string) by using it, and you free it by dropping all
pointers and letting garbage collection reclaim it.  Given that the malloc()
issues have been solved in c-client already, I'm not sure it's worth the
considerable effort of rewriting c-client in an OO language just to be able to
get rid of all the fs_give() calls, especially considering that the strictly
OO version will end up being a lot slower.

The bottom line is: it's difficult for me to see what technical benefit is
obtained by doing this.  Ordinary C, which c-client is written in, provides a
base that is much more portable (C meshes with C++, Obj-C, SmallTalk, Lisp,
etc. much better than any of the OO languages mesh with any other OO
language); it's faster, and pretty much all of the benefits of OO programming
are already in the current c-client.

It's certainly possible to re-write c-client in an OO language, and rather
straightforward at that, but it's also a lot of work with a strong likelihood
that you won't get any particular benefit from doing it.

-- Mark --

DoD #0105, R90/6 pilot  FAX: (206) 842-0758  ICBM: N 47.36'24" W 122.34'08"
TOPS-20: A Great Improvement Over Its Successors