Re: [JDEV] How to handle multiple clients

[Jeremie Miller <jeremie@netins.net>]

This is good, I like these kind of discussions :)

> i think this is a bad mode of operation. if the server stores the message,
> then we move away from having the server simply be in charge of funneling
> messages. make jabber ( & its protocol ) simple by design and by intent.
> client sends message. server pushes message to proper receiver. if there
> is no receiver or if the receiver denies the message, then server sends
> a message back to the client announcing the denial. the client is responsible
> for handling all types of errors. we'll avoid quite a few problems in the
> future if we make as little as possible happen at the server.

Well, let me stress one of the biggest features of the entire platform...
adaptability and configurability :)  There's no reason Jabber can't make
everyone happy.

Right now the server behaves exactly as you describe, bounces messages
back to the sender if the recipient isn't online.  BUT, it's just a matter
of adding a module on the server side and you could have support to store
offline messages for your account... defaults to bounces, but can be
configured to use this as a "feature".  I've tried to design *everything*
to operate this way, absolutely simplistic but anyone can plug in features
and new behaviors at any time, while still working with the same protocol,
servers, and clients :)

> it seems we have to make a decision -- jabber is just another implementation
> of ICQ and has to behave according to spec OR we improve on some of the parts
> of ICQ we don't like.

I think the answer is obvious, both :)  It should be able to operate like
ICQ if you want, or you should be able to add new features if you so
desire w/o having to change the entire system.

I don't think theres any reason to "force" a mode of operation on anyone.
The defaults should be reasonable, but clients/modules/transports should
be available to allow a user to configure their own way of doing things.

> if you have the client receive a deny request from the server, the client
> can then do whatever you want. the deny types could be:
>   . no such user
>   . user not logged into jabber server (no receiving client)
>   . user denied message

Yup... 

> in all of the three cases, you can call the same module / external email
> sender to send a mail message to the recepient.

Sure, but this is a client-authors decision, not something I would think
we could reccommend for/against.

> > Probably also the best... BUT, I think it would be cool/good if the mail
> > clients added direct support for Jabber :)
> 
> this gets into a chicken-egg contest. i don't think we'll _ever_ convince
> mail clients to add direct support for jabber. we _can_, however, design
> jabber to be extendable so we can plug-in or interface with whatever
> mail reader we want to.

Yes, it could work as a plugin, or the open-source mail clients might
adopt it and integrate it too... 

> i guess i'm still unchanged in my opinion:
>  . servers should do minimal work.

*Everyone* should do minimal work, but yes, the server should be able to
run and not have it expected to do much work, BUT if the server operator
so decided, they should be able to add any of the features they so desire.

Jabber can support the most insanely simple clients(shell scripts) all the
way up to full blown large interactive applications, and the server has to
be able to help all of them out.

>  . handling messages for resend or sending as an email message
>    should be done by the client.

Optionally, of course.

>  . jabber (client or server) should not perform email operations,
>    but dispatch then to some user-configurable program for sending
>    email.

Yes, but if someone wants to write/use a module to do so, we can't stop
them.

> another advantage to the first point is that if we maintain that servers
> will do minimal work, it will be easier for us to convince people to 
> install servers at their sites. if jabber is complicated (with either
> setup, security, or other issues), people will not be willing to install
> it so easily.

Yes, this is a very important point.  I'm planning on as the server
progresses to step out and create an insanely simple "ISP" server that is
just one executable that can be downloaded and requires no configuration
file or any other setup, just run it on boot and all of your users can use
Jabber!  But, they would be sacrificing any of the optional features that
some users might want, but that just means they can at their own pace
upgrade to gain access to more features.

I really like the one-executable idea for ISP's, and there's nothing in
Jabber that precludes this from happening...

There's no reason Jabber can't be everything everyone wanted :)

Jer