Re: Anybody working on removing sendmail from base?

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Sat, 27 Sep 2003 11:44:22 -0700 (PDT)
Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx> wrote:

> :That status bar program could poll other programs and reformat their
> :output to produce its display - but polling is just damned inelegant.
> :It would be so much nicer for it to be event-oriented somehow - to
> :receive messages whenever state that it's interested in changes.
> :
> :Anyway, at this point I'm just rambling.
> :
> :-Chris
> 
>     A status bar was a really cool feature of many of the old
>     serial-based terminals.  You could set your prompt to include an
>     escape sequence that updated the status bar.
> 
>     xterm's don't have status bars, at least I don't think they do. 
>     But they do have title bars and it should be possible to change
>     the title bar on the fly by messing with X resources.  I've never
>     bothered to try, though.
> 
>     There is also 'xbiff'.

Yes - if you're running X, there's obviously more leeway.  But that's
not really where my thoughts are about this at the moment.

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