> (I'm addressing this message to Daniel, as he seems to be the main
> developer).
I believe I am, not because I particularly want to, but because everybody else are absent.
> [att- file prefix]
>
> As now hypermail is storing the attachments in a special attachment
> directory, prefixing the attachments with "att-" becomes redundant.
> Hence, I removed it from my code.
I'm not so sure about that. You could still mail a file named '.htaccess' to get some funny effects for the particular directory where the file is stored.
> [emptydir]
>
> This function empties the attachment directory. I find it quite
> dangerous. If the user makes a mistake when configuring hypermail, he may
> erase something that he's not expecting.
>
> My solution to avoid using this function is given in the next point.
A very good solution it is too.
> [unique names for attachments]
>
> parse.c goes thru lots of problems to find a unique name. Also, if the
> mail headers don't provide a fname, it'll generate a temporary random
> name. If you regenerate an archive, links that point to those random
> names will be broken.
Eh, no, they used to, but not anymore since the previous ones are removed. But I still agree with you that your method is a better way to do it.
> As my attachment names are always the same, I don't need to call emptydir
> anymore and this cuts a bit on the overhead of running hypermail (and
> removes the risk of erasing something that you don't want).
Indeedo.
> [newdir variable name]
>
> It'd be clearer if you call it att_dir (as that's what it's being used for :)
I agree that my naming isn't always the best.
> [creation of the newdir name]
>
> It's been doing systematically for each new message. To have a better
> performance, I do it only when I'm sure were dealing with an attachment.
> This saves syscalls to allocate/deallocate memory.
Good job. I agree it is a lot better.
> In some parts of the code, you're doing a:
>
> attachname[0]=0;
>
> As attachname is a char array, you should rather do a
>
> attachname[0]='\0';
Yes, but ANSI C do handle that case. I don't disagree with you changing this though.
> [html in-line attachments]
>
> According to the HTML DTD, it's not valid embeed an HTML document inside
> another one. To make it compliant, you have to remove the <HTML><HEAD>
> and all inside it. Of course, most browsers show it correctly ... today!
> but tomorrow? As parsing the HTML is quite a pain, my solution is to
> never put it in-line, and just add a link to the document.
This has been the subject of many discussions and therefore the inline html has been an option for a while. Many people do want to have them inlined, while others are discussing the way you do here. A separate option for this leaves the decision to the guy using hypermail, letting us stay out of the philosophy. :-) Parsing the HTML to make it inline-safe has been discussed too, but so far nothing has happened there and I don't think *I* will ever try to do anything like that myself.
> [Other bug fixes, improvements]
>
> These are too numerous to cite here in detail:
I'm of course interested in getting all the patches that improves hypermail. I can't see any reason for us having two different development branches. I'd like to see us making an effort to make your changes get applied to our source base. I am willing to offer you CVS repository write access for us to achive better and faster results.
You are obviously an active improver of hypermail, and we need guys just like you. I am certain the other guys involved in this will agree.
I'm just currently a bit concerned about the mailing list that took 2 weeks to forward your mail to us subscribers...
> I'm also enclosing a torture test from RFC 2049 (it substitutes RFC
> 1806), which you can run with hypermail to see how it breaks down without
> the fixes I did :)
Hehe, well I'd better get those patches applied first then ;-)
> So, the big question is, is it worth it that I contribute my patches?
Definitely.
> It takes some of my time to make a diff between my version and yours.
> I'll continue to make the effort if they are taken into acocunt or
> refused with a reason.
I don't want to play the role of the one who got to say good or bad about your patches. I want the hypermail development community to help out and tell us what kind of functionality and improvements we want. Of course I have opinions about it, but my opinion is just as much worth as everybody elses.
> I don't like having two different hypermails, but I need to have one
> running up at our site, so I'm forced to have my own cvs base to develop
> it in a correct environment.
I fully understand that you did it this way. After all, that is exactly what I once did with the current 2a-version of hypermail. However, I hope that we can merge them into one single project as soon as possible, since we all will only gain from that.
> Some time soon, I'll start doing more proprietary changes to the code, to
> adapt it to our environment. I'd like to have at least the same code base
> as you have at that moment to avoid diverging as long as possible.
Yes. I would also like more developers on the project, so getting you into the team will make a significant change. We could probably drive the project further a lot faster after the merge has been completed.
> My next work items are:
I agree with all of them. I am sure we'll sort this out and make hypermail a better tool!
--
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 Mon 16 Aug 1999 11:17:53 PM GMT
This archive was generated by hypermail 2.3.0 : Sat 13 Mar 2010 03:46:11 AM GMT GMT