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

[Adam Theo]

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 [www.xatp.org]. 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 
http://www.jabber.org/protocol/

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
> 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.