[JDEV] Protocol (client/server division)

[Dave Smith <dave@hawthorne.net>]

Greetings...

Thought I'd throw in my two bits about this whole client/server
division matter...

Thought #1: Keep modular design 

One of the things that drew me to the jabber project was the good,
clean modular design. Deciding where to separate a client/server
program is quite a black art. For the most part, the division is
sensitive (or should be) to the application that's being developed. For
an application such as jabber, it is Very Good to keep transport apart
from the routing. If you want to be able to get a message to email,
please, please write a SMTP transport -- don't integrate it into the
router!

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.

That said...

Thought #2: Let the router route...

If we consider jabber to be a nexus of sorts, then we must be very
clear in specifying what happens to messages when they enter the
router. Dan DeMaggio painted a beautiful picture of having multiple
transports queued for delivery. If one fails, the other picks up (if
the user desires, or bounces the message).

This is a Good Thing, for several reasons:

Sub-Thought #2.1: The KISS (keep-it-simple-stupid) theory

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 don't know about the rest of you, but I have a difficult time with
complicated stuff -- can't we all just keep it simple? :)

Sub-Thought #2.2: Protecting the innocent

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. 


The downside to such a system, of course is the complication in router
configuration. It's going to take some careful design to ensure that
the router is easily configurable, without losing any of the power of
"floating" queues....

Well, my brain is empty, and I eagerly await the flames which are sure
to come... :)

D.