INNT overview..

[Fabien Tassin]

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. I prefer to start with a dedicated and
stand alone directory in the CURRENT tree.

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

> Dump NEW/DISPOSE/SIZEOF/etc.  I'd recommend dumping all of macros.h if you
> can.  I don't like anything in that file except maybe EQ and friends.

My EQ() is called streq() with a prototype a la string.h.
I'm using xmalloc() but as it conflicts with dmalloc, I'm looking for
a better name.

> that's a good enough argument; I think we can assume that people working
> on INN will know C, and you can't use C without knowing how to call
> malloc.

right.

> > - central (locked) history checks (include a builtin precommit cache)
> >   Should we remove unneeded fields in history ? I'm currently using stock
> >   dbz.c and my own API waiting for something better. I plan to use expire
> >   for a while too.
> 
> I'd like to see if you can use Alex's and see if the new history API can
> support history files with fewer fields cleanly.  I think it can;
> basically, for transit, all you need is the interface to insert an entry
> without a token.

I'm still waiting for its code but the debate seems still high.

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

> > - on the fly article preparation:

By "on the fly", I mean that data is read by block and processed by line
and the following actions are performed during block splits.

> >    - "\r\n"
> >    - Path updated
> >    - Newsgroups and Distributions headers splitted
> >    - Xref removed if present
> >   no other fields are checked/changed.
> 
> Good.
> 
> Don't forget dot-stuffing for lines beginning with a period.  Oh, and
> while you're designing the article propagation path, try to make it
> completely binary clean (including nuls) if you can.  There's no real
> reason not to, and we can always reject such articles anyway.  It's hard
> to retrofit that to an existing design.

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 ?

For binary cleanness, I have a problem with \0 but everything else should
work. I have to think more about this null problem..

> > - outgoing wishes (given in an equivalent of newsfeeds) can be:
> >   - groups including poison and groups count
> >   - distributions
> >   - pathhosts or path size
> >   - full article vs headers vs path only
> >   - size or size range
> >   See my recent syntax proposal for "newsfeeds.conf" merging incoming.conf,
> >   newsfeeds and innfeed.conf.
> 
> Right.  I'll get to that.  (I do really want the full capabilities of the
> current newsfeeds file if at all possible.)

I still think it can be done without using cryptic syntax.
I see that you've added a similar point to the TODO list, can you elaborate,
possibly using the thread I've started a few weeks ago ? This is something
I want to work on this week and I'm currently tempted to start to implement
my proposal as-is in Lex/Yacc, possibly with your hashes.

> > - storage uses the INN API, mainly for CNFS. As the article structure is
> >   different, the code must be changed (and cleaned).
> 
> Right.

I'll work on this soon.
 
> > - inn.conf equivalent for all non-peer related parameters (innt.conf ?).
> >   As for newsfeeds.conf, reloads must be as smart as possible.
> 
> inn.conf is on my list to completely rework in INN, which may make this
> easier.

good.

> > - no plan for a ctlinntd yet.
> 
> I recommend it; it's one of INN's really nice features.  It's a great way
> to be able to peak at the running state on demand without having to wait
> for periodic logs.

I want one. I've just said that I have no precise idea of it in threaded
model.
 
> > - autoconf
> > - IPv6
> > - innpeers-stat as log analyzer.
> 
> Excellent.

IPv6 is IMHO mandatory, even in CURRENT.

-- 
Fabien Tassin -+- fta at sofaraway.org