Content Description Oops

I received a number of messages in which the content-description was empty, and at the end of a line. That leads to the link to the associated attachment being anchored on null text, because the description, containing as it does a newline, is not detected as being empty in such a case. The more general problem is that a description that's entirely white is not useful as an anchor. So, my fix was to define, in parse.c,

static int hasblack(char *p)
{

   while(isspace(*p++));
   return *p ? TRUE : FALSE;
}

At line 2018 in the parse.c sources from 2.0b25, I added one line:

                  if (description && description[0] != '\0'
                      && hasblack(description))
                    desc = description;

Now, the text is anchored on the filename in the generated HTML, much better.

It's not crystal clear to me that this list is read. Could you respond? If not, I'll send it to the vanilla hypermail list in a few days.

--

I've another issue: I use hypermail very heavily in an environment where
users expect messages to be archived as soon as they are sent. To that
end, I added support for a header field cache. I use GDBM for mine, but
many other solutions could be envisioned. In my test of about 750
messages being fed one at a time into hypermail 1.02+ and 2.0b25, both
compiled with -g, I found that it took six times longer with 2.0 than
with my version of 1.02, while 2.0 takes only about 1.5 times longer for
operations where the cache isn't used. So, it's significant.

I see in the mailing list archive that another user, perhaps *two* other
users, has done something similar. In fact, I once promised Kent to make
my patches available, but failed to do so in a timely fashion. For one
thing, it seemed like a good idea to generalize it so that people
wouldn't need to install GDBM to use it, and that goal wasn't on my
critical path for anything else. So, I'm a loser. I expect to hack my
changes into 2.0b25 in the next day or so. I can certainly understand
that this isn't suitable for version 2.0, but I'd like to be sure that I
can contribute this at a later date, if it's deemed useful.

My point? Gee, I don't know.  Give core developers a chance to suggest
that I work up a sendable patch now, or that I wait for a bit, or to
tell me that an alternative approach is already in the works for
post-2.0 and I should slither back into my hole.

I'll attach to this message the tool I use to feed an mbox into
hypermail, one message at a time, as is useful for timing tests. It's
almost trivial, but maybe it will save somebody a step or two.

--

A third thought: an idiom in the hypermail code is a construct like this

  strncasecmp(a, b, n)

where n is precisely the length of the first string. That's prone to
error, because you need to count the characters correctly. Better would
be a function or macro that would either count the beans for you, or do
its own comparison that returned 0 as soon as it exhausted the first
string. Just a thought...

    -Scott Rose






application/x-perl attachment: hyperfeed.pl