[JDEV] Idea: Jabber for instrument control

[A.M. Kuchling]

I'm wondering about using the Jabber framework for instrument control,
and would like to get some advice on the design.

As part of my work, I've been working on a system for controlling a
microscope over the Internet; see
<URL:http://www.mems-exchange.org/software/microscope/> for code and
details.  While the system does work, it's not very reliable for a few
reasons, one of which is that handling both the hardware and TCP/IP
connections in one multithreaded process is tricky.  Sometimes the
hardware hangs for a second or two, or does something unexpected,
which causes a crash or hang.  I'd like to reuse other software in
order to avoid having to write and debug a server on my own, and
Jabber seems like the best candidate.  I'm thinking of the following
arrangement:

* Run a Jabber server on the microscope's computer.

* The process controlling the hardware is also a Jabber client, so it
  receives commands through the contents of Jabber messages (perhaps
  using SOAP, perhaps some new DTD I'll invent), performs the command,
  and returns a message with the new microscope position, settings,
  etc.

* Users run client software that also act as Jabber clients, receiving
  the special messages from the microscope and displaying them
  appropriately.

The big question is how to deal with images?  Some microscopes have
slow digital cameras (3 frames per second, max), but some have
framegrabbers (30 frames per second).  The jabber:x:oob namespace
provides a way to send a URL to be retrieved by the client, but this
seems unappealing; the client has to initiate the retrieval of an
image, rather than just having it be sent along.  The server would
also need to be running another server (HTTP, FTP, or something) in
order to let clients retrieve images, which goes against my goal of
reducing the complexity of the system.  Images should really be pushed
at the client, not pulled by it.  

Images could be base-64 encoded and embedded in Jabber's XML messages,
at the cost of increasing image size by 33% and requiring more XML
parsing.  (Or perhaps the image data could be embedded in a CDATA
section, but character encodings make this seem dodgy.)  Does this
seem practical?  Can Jabber servers parse only the headers of messages
in order to route them, or does the whole message have to be parsed?
Would there be some other way of sending binary files along?

On a related note, can messages be sent to multiple recipients and
routed without copying the message more often than is needed?  For
example, if client A was connected to server 1 and sent a message to
clients B and C, connected to server 2, are the Jabber servers smart
enough to send only one copy of the message from server 1 to 2?  And
can messages be marked as "bulk", so the servers can drop them if
needed (for example, if a user on a slow connection is using a 30
frame/sec microscope, there's no point in forcing every frame at them.

--amk