[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $user::user->Tell_Async ((was Re: [DotGNU]Why DotGNU should go Jabbe

From: Adam Theo
Subject: Re: $user::user->Tell_Async ((was Re: [DotGNU]Why DotGNU should go Jabber
Date: Thu, 04 Apr 2002 14:18:21 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.9) Gecko/20020313

I apologize for this 2 month late response. I have been pretty wrapped up in my offline life the past 4 months, and am just not clearing out my monsterous inbox one bit at a time. I'm back online full-time, and as a result will be pounding the streets again to get Jabber adopted by DotGNU :-)

As I've recently been explaining on the developers list, I think Jabber solves all routing problems. It will soon even be possible to do binary data over Jabber, using Jeremie Miller's new XATP []. But even without binary transfer, Jabber is a very powerful protocol.

There is too much to it for me to accurately expouse it's benefits on the list, so I urge everyone to skim through the Jabber protocol docs. Just set aside 30 minutes to do it, and you will get a really good understanding of Jabber's basic pros and cons. The docs are at

But in short, I firmly believe that SMTP (email) is quite slower than Jabber (try Jabber out and you'll see why), and certainly not as flexible. With its various XML tags and namespace extensions, Jabber is trivial to add onto. Everything is namespace-based, meaning you want to add a new feature or rule, just add a new namespace and have your code look for it and process it according to the rules you want. If it's a really good idea, submit it to the Jabber Foundation to be standardized accross all jabber clients and servers that want that functionality.

If you have any questions about Jabber, you can ask me, or better yet ask the Jabber Developers list (Jdev). They would be able to answer all your questions.

BTW, Norbert: What process do I go through to make Jabber officially adopted by DotGNU, if/when that time comes? There seems to be very little objection to Jabber in the past few days since I started promoting it again, so I think it's close to time.

Norbert Bollow wrote:
I had written:

Yes... even though I tend to be very suspicious of Microsoft's
business ambitions, I don't sense any evil in what Don Box has
actually said -- he is simply right that there is a need for a
protocol that allows to send to send the requested results
immediately or send them later in essentially the same way.

David Nicol <address@hidden> replied:

hypertext over e-mail does this quite nicely

If both the email and the webservice system are set up by the
same, reasonably competent person, yes.  (Although SMTP will
still be noticably slower than Jabber's approach.)

Otherwise I fear that such systems are likely to run into all
kinds of real life problems.  This starts with DNS set-up.
The "SomeProduct" department of Example Inc may want to run a
webservice on their primary webserver known as however they may have separate
mailserver, maintained by a different team of sysops, and there
may be an "MX" DNS record which causes all email for
address@hidden to go to

Now imagine a company-wide policy that all incoming email must
first go through a spam filter and/or virus scanner or whatever
which is installed on ... no, in order to be
successful, DotGNU needs to be easily deployable without getting
into conflict with existing corporate policies.

That is in fact a major reason why it's so popular to offer
all kinds of services piggy-back on HTTP:  Many corporate
firewalls will allow that to go through.  Instead of using email
for asynchronous message transmission, we could use HTTP POST...
not just the webservice server but also the requesting host
would run an HTTP server... just about any client-server
protocol can be turned into a P2P protocol by configuring every
node of the network to act as both client and server :-)

So Don Box is right, a replacement for HTTP is needed for the
case of requests where "full results immediately" would be nice,
but where getting the results later is acceptable also.

To use Ed Burns's distinctions in communication media, HTTP is
synchronous and Email is asynchronous.   The thing we are looking
for is asynchronous, but with a guaranteed QOS of some kind.

Actually I'm looking for a channel that supports both
synchronous and asynchronous responses.  When I send a request
then I want a response reasonably quickly, and I'd like to be
able to specify how quickly, like "please respond within 10
seconds", or whatever. This response should either contain
everything that I've asked for (if it's possible to provide that
within the time limit I gave), or something like "Request
accepted, you may expect final results within 24 hours, keep
listening on this channel."

[...] jabber:middleware [...]

If the DotGNU project
is going to include an asynchronous delivery system with guaranteed
QoS, why not just certify certain e-mail providers as having timely
enough delivery?

I don't expect this approach to be sufficiently appealing to the
users.  But it turns out that I'm wrong on this, well that'd be
absolutely great... an email-based system would be much, much
easier to hack together than the jabber:middleware based
approach that I'm envisioning.

I imagine a developer's interface where you can include the DotGnu
package into your system and dotGnu provides a layer of abstraction
between user-identity and asynchronous-delivery so that the application
programmer does not need to care if asynchronous-delivery goes via
SMTP or via jabber-messaging or gets printed to microfilm, fed-exed, and
sent on the final leg (sic) of its journey by carrier pigeon!

Firmly agreed.  Such an abstraction layer is
important... especially since we don't really know yet what
protocol will become the dominant standard.

With this in mind, I'm going to switch, in the Things I Am
Developing Towards Donating To The .GNU Project, to using an
OO-style interface where  asynchronous communication is
accomplished by invoking a method of the object that has been
mapped to the user we want to inform.

Sounds just great.

I guess I'm asking, could someone restate what the advantages of jabber messaging over SMTP are, again, and how would they appear in an application
programmer's interface to a hypothetical user::Tell_Async method?

I've written a little about the disadvantages of SMTP above, and
I could write a lot more (as there are many SMTP-related
problems that I'm intimately familiar with) but I'll leave it to
others (Adam, are you listening? :-) to expound more on the
advantages of Jabber.  Nota bene, I'm not suggesting to go via
an outside Jabber server that could become a performace
bottleneck.  The webservice server would be the Jabber server.

Greetings, Norbert.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]