> > That patch is only good for GNU make.
> True. Though the lists.h will work with a normal makefile.
Could you mail me that again please?
> I wouldn't have any objections in jumping to GNU make.
There's really no reason at this point to narrow our audience to that extent.
> It is available and the Makefile looks a lot better.
Which really isn't any strong argument in my opinion.
> They would gain a lot structure and typing errors would be harder to make.
And a whole lot less persons would be able to build it. The only sane thing to do would to introduce automake, which would be an even better way. It autogenerates Makefile.in's in a platform independent way and lets you write even less and make even less mistakes than the GNU makefile counterpart.
> But we could rewrite it to use sed and do some replacements in a
> subshell.
I wouldn't do that, I'd rather go automake instead.
> Okay, two questions for that:
> What is normal make. (E.g. is there a POSIX standard?)
AFAIK, there's no "standard". What works on most platforms is what goes.
> What is normal sed?
Same thing, only I don't think there are that many variations on sed.
> Right now I'm thinking in how hypermail and the scripts can help to
> create nice overview pages for the content of different directories, if
> e.g. saved in one archive per month.
That sure is an area we need to focus more on.
> If the message was PGP/MIME signed, hypermail should also save the signed
> message part as a seperate attachment in original form.
Hm, yeah, that sounds like a neat idea.
> The webbrowser might then be able to load the signature and the original
> message version and check the signature.
Are the web browsers really that clever today?
> It would be nice, if hypermail could somehow manage to link to thread
> messages in different month. Okay, seems hard to do, but it would
> definately be a very useful feature to follow threads, which run over
> more than one month.
Splitting the archive per month really cripples the concept of threading, yes. But to perfectly enable threading across different directories/ mailboxes, you'd need a single large database with info about the mails, threads and indexes. That brings us back to the idea where hypermail should store information about the current mbox, indexes, mails etc in a file to speed up the operations...
> My reagards to the hypermail developers, and thanks for mentioning me on
> the Website, Daniel.
I just thought I'd be a little less selfish on that page since it seems to remain there for a while. I don't want anyone but the true contributors to get the credits for the stuff they do. I am merely one of the contributors.
--
Daniel Stenberg - http://www.fts.frontec.se/~dast
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
Received on Tue 17 Aug 1999 04:00:57 PM GMT
This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT