KBIN survey

[Douglas Dodds <Dodds@YUKON.SCRC.SYMBOLICS.COM>]

    Date: Thu, 21 Dec 89 19:28 EST
    From: Dodds@YUKON.SCRC.Symbolics.COM (Douglas Dodds)

    I would like to initiate an informal customer survey about the KBIN mail
    file format that Zmail offers.
    ...
    So my survey question to the SLUG community is simply this: what is your
    feeling about the proposal to remove the ability to create KBIN files in
    Zmail?  How much would you miss it?  Do you see it as having important
    benefits to you?  To Symbolics users in general?

I want to thank all who responded to this survey; we got a lot of
constructive responses, and very quickly.  I apologize for getting
sidetracked from publishing the results for a few weeks.

The executive summary of the results is: almost all the customer
respondents wouldn't mind seeing KBIN "decommissioned", while a number of
in-house Symbolics users would be extremely pained to see it go.  The
raw figures:

  Drop KBIN?
		| Do/don't care | Please don't
    ------------|---------------|-----------------
     Customers  |      22       |        2           (total of 19 sites)
    ------------|---------------|-----------------
     Smbx users |       1.5     |        4.5
    ------------|---------------|-----------------

The executive summary of the conclusion: KBIN will not be dropped, i.e.,
nothing with change with regard to mail formats, in Genera 8.0.  We will
continue to study the issue for future releases.

------------------------------------------------------------------------------

In those responses that contained discussion, there were a few running
themes.

(1) Whatever other issues there may be, we need to be able to read mail
files on other machines, so we use a text format (usually Babyl).

(2) Instead of maintaining KBIN, put the effort into improving
mail-parsing performance.

(2a) ...put the effort into improving Zmail functionality.

(3) If you do drop it, make sure there is lots of help for converting to
other formats.

Interestingly, those who don't use KBIN or wouldn't mind seeing it go
seldom cited bugginess or inherent unrobustness as a reason.  A few did.

My synthesis of the responses that I got was that KBIN had been a
limited success in the area for which it was intended, to make input of
large mail files viable.  Limited in that its inherent disadvantages
were too large for many users; but enough of a success that it would be
cruel to remove it from those who use it heavily, without greatly
improving parsing performance for text mail.

Since we don't have a good resolution for that dilemma at this time,
we're stuck with it for a while.  (We would have to keep much of the
KBIN substrate indefinitely anyway, for the benefit of existing KBIN
files.)

Brief comments on the running themes above:

(1) Those who need cross-machine usability of mail files have used, and
will continue to use Babyl, et al, of course.

(2) No great improvements in parsing performance will be included in
Genera 8.0, due to extreme shortage of resources and many goals and
projects of higher priority.  However, we will take these comments to
heart, and put any available future Zmail development cycles into
parsing performance improvements, before anything else.

(2a) Significant improvements to Zmail functionality (better filters and
mail management strategies, Statice-based mail repositories, and so on)
are not in the cards as I read them.  Zmail is a mature system, albeit
one that suffers from old age, numerous quirks, and design deficiencies.
We will maintain it, but we must turn our development resources to more
productive projects in the immediate future.

(3) Let me assure you again, as I did in the original message, that
there would be generous conversion help, should be ever do this:
  Customers would not be stranded by this; existing KBIN files could still
  be read.  But the format could not be written, so for a KBIN buffer the
  user would be obliged to pick a new format, e.g., Babyl.  We would also
  supply conversion tools for efficient bulk conversion of existing files.

I will be replying individually to some of the respondents who raised
points that merited more detailed discussion.  It will take me a few
days to get through the list.

Again, thanks to the SLUG community for participating in this survey.
It was very useful in making a decision on the proximate question, and
in furnishing data for future planning.  We are encourage to use this
approach again, on other topics (already have, I believe).