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

[David Nicol]

Norbert Bollow wrote:
> 
> > > http://zdnet.com.com/2100-1105-845220.html
> >
> > I wouldn't be too concerned.  HTTP does publication
> > extreamly well, and the www browser is ubiquitous.
> > RPC servers other purposes.
> 
> 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.

hypertext over e-mail does this quite nicely

> This is not a good solution though.  Email systems are often
> administered by different people using different tools from what
> it used for administering "web stuff".  This kind of system
> would simply not be robust enough.  A system is needed which,
> when tested in a simple situation (that results in an immediate
> response) will also work in complex situations (where results
> are not available immediately).

the end-to-end administration is not under one hat, but e-mail
is standard enough so that it is possible to have near certainty
of getting out what you put in, but it is true, timely delivery
is not guaranteed.
 
> 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.


> [...] 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?



Oh no, I've joined an endless argument...

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! 

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.

Tell_Async seems kind of cold.  "Tell" might be good, this is a function
that will be used often and should therefore be a short word.  "Message"
is used a lot; if the suggested implementation of anychrnouhs comm. is
jabber messaging (along with SMTP) Message makes sense. "mail" is kind
of traditional.  Depending on which language you're working in,
the arguments Subject, Extended-headers(if defined at all), Body are all
the arguments the method needs, and an implementation of user::Tell_Async
based on e-mail is a piece of cake to write, due to SMTP infrastructure.

The question becomes, "What other asynchronous protocols does dotGNU 
support?" and very soon that turns into standard addresses for this that
and the other and relaying issues, relaying between standard SMTP and the
dotgnu/Jabber messaging cloud, and is a an interface for that at the
application programming library level really needed beyond choosing a
convention for the addressing syntax?

Jabber IDs look a lot like e-mail addresses, and often they do double duty.
Maybe the dotGNU async messaging checks for address validity as a jabber-ID
rather than a SMTP-ID before dispatching the message to the next courier?
And maybe a user's home jabber node forwards their jabber messages into
an e-mail box for them, perhaps making jabber an end run around a slow
SMTP spool (such as appears, or did last year anyway, at kc.rr.com), which
might fail as soon as jabber messaging servers get overloaded.



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?




-- 
           David L Nicol, humble system administrator (816) 235 1187
              "... security through transparency." -- Margareta Wolf