[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