Re: Anybody working on removing sendmail from base?

[Timothy Cava <timothy@xxxxxxxxxxxx>]

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

Timothy Cava wrote:
> 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
> 

Whoa, IPC != IRC. Spaced...Ignore me.

-Timothy