Subject: babyl format driver?

From: "K. Richard Pixley" <[email-masked]>
Date: Thu, 25 Jul 2002 00:06:54 -0700

Is anyone aware of a babyl format, (ie, emacs rmail format), driver
for c-client?

And if not, and were I to write such a thing, could anyone tell me
what would be required in order to see such a driver incorporated into
the standard releases?

--ric
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Tue, 20 Aug 2002 14:21:23 -0700 (Pacific Daylight Time)

> Is anyone aware of a babyl format, (ie, emacs rmail format), driver

I don't know of one, and I don't know enough about Babyl format to write
one.

> what would be required in order to see such a driver incorporated into

The main issue is support.  I don't know enough about Babyl to support it
myself, but including it in the official distribution implies support.  It
also would get me flamed if it had problems (e.g. was slow, or violated
some aspect of the Babyl specification).

In such cases, I encourage third-party distribution.  That way, the
support for Babyl would be in the hands of the Babyl user community, who
are in a better position to support Babyl than I am.  Similar
issues apply to Maildir format.

I'll be happy to answer technical questions for anyone who purposes to
write a Babyl driver (e.g. what c-client expects).  I suggest that you (or
whomever) start with an existing driver with similar characteristics and
use it as a prototype for the new driver.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

---

From: "K. Richard Pixley" <[email-masked]>
Date: Tue, 20 Aug 2002 16:15:33 -0700

> I don't know of one, and I don't know enough about Babyl format to write

Me either, but I have emacs for samples, and a fair understanding of 
it's capabilities.  (flat file format with labels).  :-).

http://www.ifi.uio.no/~larsi/notes/BABYL.  It's about a 2 minute read. 
This file is also in the emacs distributions as etc/BABYL, so you prolly 
have a copy on your machine already.  :-).

The format is easy to recognize and the emacs mechanism for file locking 
is simple, though advisory.

The only tricky part I see is whether to support the inbox chaining akin 
to the /var/spool/mail/rich -> ~rich/mbox relationship.

Here's the only other reference I found in a short web search.  Likely, 
the format was never formally documented.

http://web.mit.edu/dosathena/TechMail/Misc/BABYL

 > some aspect of the Babyl specification).

As far as I can tell, babyl is a dead format.  It's use in emacs rmail 
is just a carry-over from tops-20 days.  Emacs-rmail is getting pretty 
moldy these days with only rudimentary pop support, no imap support, 
awkward mime support, and with the other emacs mail readers available, 
little motivation to update.  I intend to move away from it personally, 
(finally), but I have several decades worth of mail archives, (many 
offline), which I really can't practically convert.

 > issues apply to Maildir format.

a) I don't think there is a babyl community per se.

My web search produced several dozen utilities for converting FROM babyl 
back to mbox format, since the later emacs readers didn't initially have 
babyl capability and the emacs support for conversion at the time was 
tedious, (message at a time), these things sprouted like weeds.

I'm also aware of a python library for reading babyl.  A perl reader, 
backends for several more general mail user agents, (emacs vm, mm, gnus, 
imail, and a few others), etc.  All have been produced for reading 
emacs-rmail output.  I don't think any of the original babyl format 
programs survive.

b) support is my issue as well.  From where I sit, babyl format is 
extremely static, (hasn't changed in 2 decades?), while the stucture in 
which it would live, c-client, is still live code.  So from out here, it 
looks like it would be better supported inside, since infrastructure 
changes are much easier to do in parallel across formats than they are 
to do serially across N backends by N developers.

c) Then there's the ongoing maintenance issue.  If I get babyl format 
into some (main line) imap server, then I can forget about it and the 
next redhat/suse/blinux/whatever will be babyl capable.  If I'm forced 
to maintain diffs, then I'm forced to update/repatch/recompile every 
time I reload or update my os.

d) and we have the pointer/wheel issue.  If it's in the main line, then 
anyone who might want it, has it.  If it's out here maintained 
separately, then how does anyone find it?  Like, how would we know if 
someone had already done a babyl driver?

e) finally, there's elegance.  Frankly, if I'm going to move to imap and 
a server based architecture, I want to also consolidate the number of 
esoteric readers.  Putting them into the imap server seems like exactly 
the right choice to me, (as opposed to putting them into mozilla and 
balsa and mutt and etc, etc, etc.)

 > use it as a prototype for the new driver.

I'm not really willing to patch and recompile c-client every time a new 
version is released and/or every time I reload redhat.  That's just not 
feasible.  I'll do it for a short time, while the driver is in 
development, but I want to work toward a time when it's merged into the 
main line and can be largely forgotten.

So if there's no hope of getting it into the main line code, then it's a 
stillborn project.  I'll have to find some other solution.

Am I correct in understanding that Cyrus uses it's own storage format 
and ONLY it's own format?

--rich

---

From: Mark Crispin <[email-masked]>
Date: Thu, 22 Aug 2002 12:10:39 -0700 (PDT)

> it's capabilities.  (flat file format with labels).  :-).

I have a similar understanding.  However, I am *very* leery of implementing
based upon that understanding.  The people who use Babyl tend to be either
fellow cranky oldtimers from the 1970s, or modern-day GNU fanatics.  Neither
group is particularly ameniable to anything that could be perceived as "taking
over" their world.

If one of them makes an implementation mistake, it's a bug.  If I make the
same implementation mistake, it's hostile action.

All you have to do is see how people react to things that Microsoft has done
over the years.  Microsoft certainly has committed abundant hostile actions
over the years, and continues to do so.  But they also get flamed over matters
that are legitimate mistakes.  The "open source community" is not a very
friendly one.

> is just a carry-over from tops-20 days.

Actually, a carry-over from ITS days (which predates TOPS-20).  But now that
you mention TOPS-20, that raises up another matter.  I was the developer of
the most popular TOPS-20 mailsystem, and effectively had the monopoly on the
mailer daemon, mailbox namespace, and SMTP server.  I had a large share of the
MUA as well, but there were others...including Babyl.

> back to mbox format

If you can do that, then you can then convert to any other format since there
are many utilities which convert from mbox format.  This includes not only my
own mailutil program (many formats), but also programs which the maildir and
Cyrus communities have if you choose to go that route.

> I don't think any of the original babyl format
> programs survive.

I have TECO source for the original BABYL on my TOPS-20 system:
@v emacs:bab*.emacs

   PANDA:<EMACS>
 BABYL.EMACS.773;P775252  110 56034(36)  30-Jun-85 09:57:03 KRONJ
 BABYLM.EMACS.164;P775252  33 83232(7)    8-Aug-85 21:51:52 KRONJ

 Total of 143 pages in 2 files
@

but I no longer possess the skills to understand MIT TECO programs.  I never
used Babyl.

> time I reload or update my os.

I have good news in that department.  c-client uses a "driver" type
technology, so that the only "patches" that need to be maintained are the
creation of the babyl.[ch] files to implement the driver and adding "babyl" to
the list of drivers in the Makefile.

Unlike patches, drivers tend not to have compatibility issues between releases
of c-client.  The last major compatibility issue that required changes in all
drivers was several years ago.  So, it is likely that you can write a driver
now and have it continue to work in future versions.

> If it's out here maintained

Web searches should solve this.  I would also encourage the driver to be given
to the GNU emacs people (since emacs rmail is the main user today) as
something that they distribute.  The qmail people distribute a maildir driver
for c-client in a similar mechanism.

> version is released and/or every time I reload redhat.

As I said, the good news is that you shouldn't have to do that.  You should be
able to write the driver once.  I think -- I am not sure -- that Redhat
already adds a maildir driver to their distribution of c-client, so it
probably is feasible to talk them into adding a babyl driver too.

> and ONLY it's own format?

That is correct.  Cyrus is highly optimized for that format as well.