[JDEV] UNSUBSCRIBE

[Joe Osowski]

UNSUBSCRIBE

> -----Original Message-----
> From: jdev-admin at jabber.org [mailto:jdev-admin at jabber.org]On Behalf Of
> mark at mjwilcox.com
> Sent: Sunday, January 07, 2001 5:44 PM
> To: jdev at jabber.org
> Subject: Re: [JDEV] Idea: Jabber for instrument control
> 
> 
> How about as an option for the images to use the new Scalable 
> Vector Graphics (SVG) image standard. One of the benefits of 
> SVG is that it's an XML based format. 
> 
> The Apache group (courtesy of work donated by Sun) has an 
> excellent Java API and viewer called Batik (xml.apache.org/batik).  
> I've run it on Linux and it works pretty cool (don't know if does 
> animations yet).
> 
> And I already think Batik has code to transform from SVG to JPEG 
> & PNG. Thus you could use Jabber as your transport mechanism 
> (and you could just use normal Jabber messages, don't need 
> OOB). Then either use an SVG viewer or convert to another format 
> for Web display.
> 
> There's also a SVG Perl module (sorry don't have URL). 
> 
>  Adobe has an SVG viewer for Windows and Mac at 
> http://www.adobe.com/svg/viewer/install/beta.htm.
> 
> The SVG homepage is at:
> http://www.w3.org/Graphics/SVG/
> 
> Good luck,
> 
> Mark
> 
> 
> On 6 Jan 01, at 10:40, A.M. Kuchling wrote:
> 
> > 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
> > 
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> > 
> > 
> 
> 
> Mark Wilcox
> mark at mjwilcox.com
> Got LDAP?
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>