[ANN] Jabber
Brian Brown
rbb at techgame.net
Thu Jun 26 18:15:33 UTC 2003
On Thursday 26 June 2003 11:10 am, Daniel Vainsencher wrote:
> [Technical jabber stuff]
> Interesting..
>
> [jabber based infrastructure]
> What kinds of things did it do (that you can talk about)? Any parallel
> to stuff we need? Could it be used to drive a test server, for example?
>
Well, basically the system created a software layer over disparate hardware
like Audio Visual equipment (video switches, vcrs, dvds, etc.), security
cameras, door alarms, card readers, keyboard/video/mouse (kvm) switches,
network attached serial devices, etc.... you name it. Each of the hardware
devices in a particular installation was represented by a software proxy,
which happened to be a jabber client. A user of the system had a desktop
environment that allowed him to control the devices (i.e., press play on a
VCR) and route Video from a source (computer, vcr, sattellite feed) to a
destination (monitor, video wall, or a window on his desktop). From a video
perspective, all the routing was done by controlling video switching and kvm
switch equipment, so it was really analog as opposed to digitizing and
encapsulating video, but in conjunction with a video overlay processor (from
RGB Spectrum or Miranda), you could have 9 different video/computer feeds on
your desktop at one time, all in their own resizable, movable windows.
Anyway, from a Jabber perspective, each client desktop was a jabber client,
each device, source, and destination in the system was a jabber client, and
the processes that encapsulated the non-client logic were all jabber clients.
This had some interesting effects - for one, any piece of the system could be
in any location, as long as it was accessible from a TCP/IP perspective. Each
of those jabber clients creates a "Presence" in the system... we used the
presence information to indicate the status of devices. If an admin wanted to
make some resource unavailable, the Presence status would be changed, and all
of the clients that were subscribed to that Presence would update their GUI
(if applicable) to show the correct status, as well as disable menus etc. so
action could not be taken on unavailable resources.
Also, from a fault tolerant perspective, Jabber makes use of "Resource"
strings... i.e. user at jabberserver.org/MyResource. This allows someone to be
logged in multiple places at once, and each Resource can be assigned a
priority. If a message is sent to the Jabber ID (JID) without a resource, it
goes to the highest priority resource, but if the resource is specified, it
only goes to that one. And if a resource is unavailable, it will go to the
next highest priority. Using this, a simple geographically disparate failover
system can be implemented.
What else should I ramble about... we implemented a sophisticated
subject-observer pattern complete with priorities, voting, etc for any
namespace... you just registered for a namespace (jabber message/xml) and you
then received any of those messages. Allowed our logging system to be
transparent and as verbose as you wanted.
The fact that all of our code was in Python didn't matter to the Jabber
server... you can also write modules for jabber, which are shared libraries
loaded in to the server, but we never needed to write one.
I just wish I knew about Squeak then :-)
Brian
P.S. I think the bottom line is that the protocol can easily be used to do any
and all of the kinds of things people have been discussing on the list; drive
test servers, blogs, swikis, remote images, code updates, you name it :)
More information about the Squeak-dev
mailing list
|