Re: [JDEV] Protocol (client/server division)

["Donovan Schulteis" <sculdheizo@mindless.com>]

I'm going to jump back in, even though I'm not developing, yet (although the
way you guys are peaking my interest, that's bound to be sooner rather than
later!)

>Thought #1: Keep modular design

>
>One of the things that drew me to the jabber project was the good,
>clean modular design.
>[...]
>I see jabber as more of a means to the End, rather than the End. I
>believe it is (and should be) a framework upon which to hang nifty
>modules that allow different proprietary protocols to talk sensibly --
>a nexus, if you will.


Keep that thought, for sure!!!

>I've seen much raving about new tags for sending messages via email. I
>*strongly* disagree with this approach. The protocol should *not* be
>tied to transports -- otherwise we get coupling between transport and
>routing. Ideally, the client should know *nothing* about what
>transports are available, it should just send the message and see if it
>bounces. This approach keeps the protocol clean, the client simple to
>implement, and the transport modules simple (since there is only one
>contingency to plan for).


I agree with this.  When I said "tag", I meant it in a similar scenario to
this:

person A wants to send person B (on separate servers) an instant message.
When server B bounces that message back to person A, that "CLIENT" knows
that a bounce means that person B was not connected to server B.  The client
then states a little blurb (such as:  [person B] is not available at this
time.), and then asks the question: Do you want to send the message to
[person B] via email?   If person A does want to send via email, the client
would "tag" the same message with some sort of a true/false variable ( email
= y ), in which server B would not check other transports when receiving a
message "tagged" as such, and automatically send the message to the SMTP
transport.  This would allow the recipient the ability to block instant
messages if desired and obscure their real email address (if that is what
they wished to do).  Email servers always are online (at least the general
public hopes), and the ability to send a message via the Jabber email
transport always exists.  Therefore, unless the sender wishes to send a
message via email (either initially or because no other transports were
available), the email transport should not be involved.  It should remain an
option or a last resort of delivery.  This also addresses the following cut:

>By having a design which permits several, or no transports queued for
>delivery, you provide a level of protection for the Innocents (or those
>who would be spammed, bothered, etc). If I'm having a bad day, it would
>be nice to route all my messages to an "answering machine" so I can
>deal with reality at a later time.


Anyways, I hope I'm not making any of the REAL and NOW developers mad!

Donovan