Fun with X and CORBA

[Shawn T. Rutledge]

Last night I wrote my first X program.  (I've used C++ on OS/2 and
Windows, and a lot of Java/AWT, but never plain old C and Xlib.  X
widget libraries have always seemed a lot more intimidating and
hard to get started with than AWT or MFC.)

I want to write a reusable guage/meter component that can be used to 
show any kind of measured values.  Right now I want some gauges to show 
weather measurements on my desktop (I have a weather station, you can see 
its measurements at http://gw.kb7pwd.ampr.org/weather/) but as long as I'm 
at it, figured they might as well be reusable components.  I started
with the source to xsclock (one of the simplest of analog clocks, 
which uses no widget libraries, only Xlib itself) and
started abstracting the concepts of hands, sets of tick marks, etc.
so that there can be multiple ones at once, representing arbitrary 
ranges of values over arbitrary ranges of angles on the dial.  Then 
I got to thinking about how to get the values that are going to be
displayed.... what would be the most universal.  I could use XML, but
there are a couple ways to do that... I could have the gauge component
get XML from the web server, and use expat to parse it, but it would 
probably be slow.  The web server and the PHP code to generate the XML
would add a lot of overhead; even now my weather page takes several 
seconds to load (most of the overhead is probably database access) 
and I want a much faster refresh rate for these gauges.  There are a 
lot of Java solutions (JavaSpaces, RMI, JMS, ...) but I'd rather not
depend on running Java just for a small problem like this; because every
Java process takes a lot of memory, and it's still not common to be 
able to run a lot of Java processes all in the same VM (if it were, then
I would have many uses for it, and all of them collectively could perhaps
justify the overhead.  But there would need to be a command-line method
to load a new class with its own "main()" into the same VM, and run
it along with all the other processes in that same VM.  And also
easily kill processes at will, without killing the whole VM.)

Or, I could have the XML be written to a file every time the values
change, and another process read the file.  But then there would be
synchronization issues.

Or, I could write every value to a different file, with no adornment...
just the number.  Maybe with so little data being written, synchronization
wouldn't be as big an issue.  As a bonus, I could test the gauge by
getting values from /dev/random.  But it's not quite as universal
a solution.  I wonder if I could set up a pipe in the filesystem
to another machine, so that the server writes to the pipe and the 
client reads from it.  But I'm not sure how to do that.

Anyway... what might make the most sense is CORBA.  The standard includes
an event service.  I'd like to have a daemon which monitors the weather
instruments, and broadcasts an event every time there is a change in 
any of the values being measured.  Then I'd modify the perl script that
I currently have, to get the values that way and insert them into the
database rather than trying to read directly from the hardware.  The
daemon would be able to send events to multiple recipients, therefore
the gauges could get them in real-time without database latency.  On
the desktop where the gauges are being displayed, it would make most
sense to use the ORBit ORB, because it will be running anyway because
I use Gnome.  But alas, it doesn't seem to have an event service.  I
remember this came up at my last job... even most of the commercial
ORBs didn't implement that part of the specification.  So I'm wondering
just what they expect you to do, when you need to implement the 
publish/subscribe pattern... use method calls?  But it seems like
CORBA assumes a strict client-server relationship; the client can
definitely call methods on server-side objects, but I'm not sure if the
server can call the client.  I don't know if a callback method is 
possible.  If it is, then the client could call a method on the server
to register, and the server would call a method on the client to notify
him that a value has changed.  That would be the classic implementation
of the observer pattern.

Or I could try to use a separate message broker (MOM - message oriented
middleware).  I'm reading about it in the context of JMS at work.  But
the free implementations of that idea all seem to be pure Java, and
the non-Java solutions are old commercial ones from companies like
IBM etc... this technology apparently goes way back to the mainframe
days as well.

Solving this problem might enable me to solve some others as well.  I
want to implement a sort of universal reminder service in Nettebook,
so that if I have an appointment, it can send a message to a computer
in the bedroom to play a sound to get me out of bed, or send a pager
message (if I had a pager, which I don't) or ring a phone somewhere and
play a sound via the voice-modem, or email, or just insert an appointment 
into my Palm ahead of time so that it will remind me.  The notification
sources will get smarter over time; I want to integrate my phone system
so that I'm notified if somebody important calls, but the phone doesn't
ring if it's just a telemarketer.  So again I need cross-platform events 
and CORBA or MOM would seem to be the most universal.

-- 
  _______                   Shawn T. Rutledge / KB7PWD  ecloud@bigfoot.com
 (_  | |_)          http://www.bigfoot.com/~ecloud  kb7pwd@kb7pwd.ampr.org
 __) | | \________________________________________________________________
Get money for spare CPU cycles at http://www.ProcessTree.com/?sponsor=5903