[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] What are and what should be the qualifications for a c

From: Ken Hornstein
Subject: Re: [Nmh-workers] What are and what should be the qualifications for a current nmh user
Date: Mon, 17 Nov 2014 13:17:12 -0500

>Don't shoot, Robert, but
>I think it's time MH took its turn in the refactory.

I don't disagree with any of the things you've said regarding architecture
(and Norm, thanks for providing that followup), but some annoying real-world
software engineering issues pop into my head:

- When I hear people suggesting using the 9p code as the mailstore, my
  reaction is the same as I had when people were suggesting the use of
  imapfs, "Um, great ... let us all know when YOU get that working!".
  I can't really get behind that as a portable solution, but please don't
  let me stop you from working on that; I'm willing to entertain that
  I might be totally wrong here.

- The idea of a "MH++ mailstore" ... well, my first question is: Who, EXACTLY,
  is writing that code?

  I'm personally not interesting in writing that code.  David Levine and I
  are the two biggest contributors to nmh in the past few years, and I'll let
  him speak to whether or not he wants to write that code.  If someone else
  wants to write that code, then please, speak up!

  I don't want to write that code because ...

  a) It's a lot of code, which means it will take a long time to write it.
     My time is limited; what I want to do now will take long enough, and I
     don't have any idea how long MH++ mailstore will take.

  b) The tools I personally use (the base nmh tools and exmh) will not see
     any advantage to MH++ mailstore.  I've already written about the state
     of 3rd party programs that use the MH mailstore; suffice it to say that
     I don't see anyone adapting to the new mailstore anytime soon.

  c) I am not yet convinced it's the right thing to do.  This is not a strong
     conviction; I can still be persuaded.  Mike and Ralph's arguments have a
     lot of weight behind them, and I am partially there.  But the practical
     concerns outlined in a) and b) get in the way.

- As for an interface that intercepts system calls using LD_PRELOAD or some
  similar mechanism ... ugh.  I've done that for other things, and it
  ends up being a HUGE pain due to various differences between operating
  systems.  We have enough trouble with people being able to get a valid
  DBM library on Linux; I cannot even imagine what the support issues would
  be there.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]