[JDEV] Jabber as COM/DCOM replacement for linux.

[ogeorge at lor.jeremie.com]

Quoting tom berger <object at blinx.de>:

> 
> great idea. only it's not COM/DCOM that should be replaced. let
> us leave that to bonobo (actually, is someone already working
> on a jabber bonobo control, to replace jabberCOM ? i'm interested)...
> 
> what i see, is a bottom-line tool for creating 'web' applications.
> 
> my experience with web applications showed me the need for a
> simple asynchronous protocol. you see, all the big corp. are
> trying and trying, and they just cant do. microsoft is doing
> it the COM way, ibm tries to do it the 'geeky' way, and supports
> linux and java, oracle and sybase, borland, all of them. they
> try to give you the  r e a l   p o w e r   of html (they all
> know very little about that, but they learn fast).
> 
> when i saw jabberzilla for the first time a few days ago, all
> i could think about was that this is something that everyone
> is waiting for since a long time. because on the web, you cannot
> really work with flash, java, COM and their friends. you cant,
> because you knoe that doesn't matter what you do, you always
> end up with 90% protocol. the other 10% is browser bugs and some
> content. fot those of you who do not browse the web (especially
> the people that do not use a modern browser) : people have been
> doing all kind of really bizarre things on the web, utilizing
> very simple cgi scripts, some clever javascripting, some basic
> html. all of this, for a simple thing. to run an asyncronous
> query or two.
> 
> jabber is nothing like COM. it is simple. and jabber::middleware
> should be targeting exactly this niche. the simple, low-tech
> technology can really benefit from it, and, it doesn't take much
> to get there.
> 
> simple things stick. this is why html became big enough for people
> to try using for what it shouldn't be used. i'm sure that if
> jabber::middleware will be as simple, you  w i l l  find it being
> used as a replacement for corba one day :)
> 
> tom
>

I agree with that, and while the thoughts are fresh here are some specifics i 
think relate to this issue directly.

For web client applications which want to be compatible with clients which are 
stuck behind http proxies then XML-RPC or SOAP is fantastic.  This means a 
normal HTTP GET can invoke a particular function of a particular named object 
on the server and get a response in the reply in a wonderfully generic manner.  
This is good for Flash , and Java but i think is an impossible protocol to 
implement in Javascript (someone feel free to tell me i'm wrong, i want to 
be).  The downside to this interface is that you loose the whole 'presence' 
idea unless you have a webclient-transport which does timeouts on inactivity.

Any solution proposed should consider clients which interface through HTTP GET 
protocol, which I think means that they have less 'features'.

Just thoughts, Oliver.