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

[Norbert Bollow]

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
someproduct.example.com 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 mail.example.com

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 mail.example.com ... 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.

-- 
A founder of the http://DotGNU.org project and Steering Committee member
Norbert Bollow, Weidlistr.18, CH-8624 Gruet   (near Zurich, Switzerland)
Tel +41 1 972 20 59       Fax +41 1 972 20 69      http://thinkcoach.com
List hosting with GNU Mailman on your own domain name   http://cisto.com