rra at stanford.edu
Sun Mar 11 06:29:58 UTC 2001
Fabien Tassin <fta at sofaraway.org> writes:
> According to Russ Allbery:
>> I'd really like to put INNT into the same source tree as INN so that we
>> can put it into CURRENT and it can get more exposure that way, but that
>> doesn't mean it needs to share anything with INN other than the
>> configuration and build system (and I can help merge that in).
> sharing configure stuffs adds limitations to INNT as INN requires a lot
> of stuffs that I'm not using.
Sorry, I didn't quite follow that. What limitations does it add? Just
the length of time it takes to run configure, or something else?
> I prefer to start with a dedicated and stand alone directory in the
> CURRENT tree.
That's largely what I meant for the code, but I thought maybe it could
share the same top-level configure script, and maybe some of the other
machinery like dependency generation?
>> I do think using libinn (and making the parts of libinn that you need
>> thread-safe) is a good thing to do and I'd like to help with that.
> I don't like libinn in its current form. I really would like to see
> smaller libs with dedicated sets of tasks.
Could you let me know what about it you don't like in particular? I'd
really like to clean up libinn as much as I can; there are parts of it
(sometimes large parts) that I haven't gotten to yet, but I think most of
the new stuff that's been put in or cleaned up is pretty solid and
> My EQ() is called streq() with a prototype a la string.h.
Hm. It'd be ideal if we could be consistent.
> I'm using xmalloc() but as it conflicts with dmalloc, I'm looking for a
> better name.
How does it conflict with dmalloc? Maybe I can help resolve the conflict?
My intention was for xmalloc to be more generally useful than even just in
INN, and I have an interest in making sure it doesn't have serious
conflicts with other packages.
>>> Should I check message-id syntax ?
>> Yes, please. But you may not want to use the code in INN; instead,
>> something closer to the current MESSFOR and USEFOR stuff would be
>> better. I can take a look at this at some point....
> place for another API ?? If you can provide one, you are welcome.
Sounds good to me. This is the sort of thing that I think should be in
> I'm not touching to dots but I'm changing EOL to always be CRLF. I
> understand it is not mandatory and perhaps even not desirable but it was
> a design choice. It is not time consuming in the way I've implemented
> it. Should I remove it ?
Ahh... okay, sorry, I understand now. Hm. I'd tend to remove that; I
think a completely clean path is more important than trying to correct for
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers