fta at sofaraway.org
Mon Mar 5 13:22:51 UTC 2001
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
> > - 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.
> 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).
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
> > - 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
> > - autoconf
> > - IPv6
> > - innpeers-stat as log analyzer.
IPv6 is IMHO mandatory, even in CURRENT.
Fabien Tassin -+- fta at sofaraway.org
More information about the inn-workers