Re: xinetd feature: daemons that listen on multiple ports

Hello,

All that's truly needed in xinetd is the ability to define
an address list for the bind parameter. Just that one thing
would get us the most flexibility for the effort. This is
what other inetd's do.

I would also say that passing data structures around goes
against what all other inetd's do. Over the last month,
I've been writing the specifications for a new inetd.

I am wanting to try an experiment. Everyone has heard of
the CMMI technique. I am curious if that works for Open
Source projects as well. I surveyed all inetd's I could to
see what they do and put that into a requirements document.
The requirements are most of the way done. This would be
the RRP milestone. I also have a pretty good start on the
UML diagrams to take it to a PDR stage.

Writing new requirements has also been educational. I've
found several areas that xinetd's behavior is different
that other inetd's. Then there's IPsec and SASL. I don't
like the idea of squeezing that into xinetd as it stands.

One of the reasons I'm doing this is that I think the
xinetd code, even though its better than 2 years ago, is
way too fragile to be doing heavy changes in. 2.3.12 is
very stable compared to what we've had in a long time that
I'm reluctant to see major changes in that code base.

Starting over with a clean sheet would be a better way to
go in my opinion. For example, the sio library which has
caused so much pain over the last year is not needed at
all. If xinetd did a lot of I/O, it might make a
difference. All its used for is reading the configuration,
writing to the log if file logging is used, and writing a
state dump. As for the log files, we write one sentence and
close the file. There is no real gain, but we have had a
lot of pain. Reading config files and dumping state are
perfectly fine with read() & write().

IPsec and SASL and other things should be designed in from
the ground up. Each module should have its own unit test
that exercises it. Each module can be swung in and out at
compile time. People that want a lean inetd can compile
just the pieces they need. Vendors can compile the whole
thing.

My personal thoughts is that we should leave the xinetd
code alone and start a new version from scratch. Only do
bug fixes in the 2.3 series. My 2 cents.

-Steve Grubb

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com