[Standards-JIG] proto-JEP: Smart Presence Distribution

Michal vorner Vaner michal.vaner at kdemail.net
Wed May 17 19:07:18 UTC 2006


On Wed, May 17, 2006 at 07:47:47PM +0200, Philipp Hancke wrote:
> Michal vorner Vaner wrote:
> >And no, you can send message to more people even with this jabber
> >protocol. You have MUCs, 
> which is using the same distribution strategy.
> Even IRC is more intelligent.

Well, jabber is IM protocol, not conference and public help. They aim at
different goals. IRC does not have real identities, does not
interoperate in each-to-each manner (using IRC for chatting with my
friends would mean I would need 5 or so IRC connections to many IRC
networks).

And IRC has an advantage the one whole network belongs to one group.

And, by the way, IRC does it the same way as jabber, from a different
point of view. One networks means one jabber domain (which may consist
of more real servers and the comunication between them can be done
anyhow you want), one message is sent to the network and is multiplied
to many connections. It is how MUC does it.

> >send more stanzas. Where is the problem? Who do you think will take his
> >long hours to write, debug and maintain this thing that will save _few
> >bytes_. In the meantime he writes it, we will have double the fast
> >lines.
> 3. Bandwidth is infinite.
> The Eight Fallacies of Distributed Computing by Peter Deutsch
> http://today.java.net/jag/Fallacies.html

Where did you see infinite? I said these few bytes do not worth the time
to optimize. I just said human time is far more expensive than the
bandwith.

And, why do you point distributed computing here anyway? Point that to
BOINC.

And, if it really matters to you, place the connection under TLS, it
compresses the data before encryption, you gain security by it as well
and have libraries for it already.

> >>If the rosters are not in sync, it doesn't matter if they aren't in sync
> >>on the sender's or on the receiver's side. If so far you were able to live
> >>with occasional glitches and occasional necessity to re-establish a
> >>subscription, the multicast variant of the operation won't make that more
> >>or less complicated. It only gives you less traffic on the network.
> >>
> >
> >I disagree here. You have the roster in more than one place. Such a
> >situation always leads to bug which are hard to detect and even harder
> >to find. This is the situation half of programing textbooks warn
> >against.
> The roster _is_ distributed in more than one place.
> E.g. if Romeo has subscribed to the presence of Juliet, this is also
> stored in Juliets roster, otherwise she would not know how to respond
> to probes properly.

Yes, and it often happens it is out of sync. Since it has not much use,
except showing user the subscription is 'both', noone actually cares.
Believe me, I already came to point where my subscription was out of
sync.

-- 

Work with computer has 2 phases. First, computer waits for the user to tell it what 
to do, then the user waits for the computer to do it. Therefore, computer work 
consists mostly of waiting.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060517/5e6c8fd2/attachment.sig>


More information about the Standards mailing list