INNT overview..

[Russ Allbery]

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
generally useful.

> 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
libinn.

> 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
common errors.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>