Re: Anybody working on removing sendmail from base?

[Timothy Cava <timothy@xxxxxxxxxxxx>]

06@xxxxxxxxxxxxxxxxxxxx> <20030927233131.4b3bd07c.cpressey@xxxxxxxxxxxxxxx>
In-Reply-To: <20030927233131.4b3bd07c.cpressey@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 67
Message-ID: <3f76bb4a$0$268$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 198.144.205.229
X-Trace: 1064745802 crater_reader.dragonflybsd.org 268 198.144.205.229
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:1320

Chris Pressey wrote:
<snip>
> 
> My thoughts are more about IPC.  Generally, IPC under Unix (under most
> OS'es actually) is a *mess*.
> 
> I *should* be able to write the statusbar program described above like:
> 
>   done := false
>   repeat
>     wait for a message from (the clock|the disk|mbmon|my mbox)
>     if the message was...
>       that the time is now X:
>         my time := X
>       that the free disk space has changed to X:
>         my disk space := X
>       that the motherboard temperature is now X:
>         my temperature := X
>       that a message was delivered to my mbox:
>         increment my new-mail counter
>       that a message was read from my mbox:
>         decrement my new-mail counter
>       a request to terminate:
>         done := true
>     display (my time + my disk space + my temp + my new-mails)
>   until done
> 
> The thing is, I *can't* write it like this, mainly because the clock,
> the disk, mbmon, and my mbox, aren't event-oriented - they don't work in
> terms of sending and receiving messages; they mostly work in terms of a
> synchronous system of "standard" input and output that is looking more
> quaint every day.  At best, I'd have to stitch together some sort of
> Frankenstein's monster of signals and named pipes and kqueues and
> polling.  It *shouldn't* be this way.
> 
> In fact that's mainly why I'm here.  I'm hoping it doesn't *have* to be
> this way.
> 
> Will DragonFlyBSD allow me to write code like the above example?  Is the
> messaging abstraction intended to be solely for the benefit of the
> 'guts' of the operating system, or will user programs be able to use it
> as well - not just for writing more efficient code, but also more
> *elegant* code?  Perhaps a stickier question still - will I *ever* be
> able to write code like this in a *portable* way...?
> 
> -Chris

Funny that you mention IRC. I'm currently writing a very modular console
IRC client that has an ircii feel. ircii's codebase is horrible, but a 
lot of the functionality is good, so I've just written my own code.
Everything is dynamic (windows, servers, numerics, etc). There's a
TCL module, a perl module, yadda yadda. It's a usuable client at this
point, other than DCC and robust key handling. I need to add things
like loading an INVEX module when it sees that a server supports INVEX 
by parsing numeric 005, stuff like that. I want to make the key handling 
generic enough to have a vi module, where you type i<whatever><esc><a 
key to send>, or you can :%s/mstke/mistake, etc. Just for fun. :-)
The screen handling is already generic enough that if somebody wrote a 
GTK module, you hook it to the screen parts on load and now you have 
your IRC output both on a console and in X11. The logging code is just 
on the screen stack, things like that. You can hook stdin in to the 
server_read stuff (my client uses libevent, which falls to kqueue) and 
type lines to see how the client reacts, this is good for looking for 
overflows or regression style things...

-Timothy