[Standards-JIG] proto-JEP: Smart Presence Distribution
Michal vorner Vaner
michal.vaner at kdemail.net
Thu May 18 08:04:04 UTC 2006
On Wed, May 17, 2006 at 10:48:07PM +0200, Carlo v. Loesch wrote:
> Richard Dobson typeth:
> | What makes you suppose that? We usually prefer to look longer term when
> | developing protocols here, and prefer to develop solutions that will not
> | break or are against the existing protocol, we prefer to extend.
> Even the JEP as it is posted to the inbox doesn't break anything.
> The current suggestion is, if the user is using privacy lists on any
> target of a particular server, to revert to the current distribution
> method, thus a fan out with exceptions.
> It would be good to know, if even this simple approach already brings
> relevant traffic decrease. We have no figures on that.
> Concerning the problem of keeping subscriptions in sync:
> What's bad about occasionally having your server re-issue subscribed
> and unsubscribed messages during off hours, so that the server network
> slowly cleans out sync problems. wouldn't it be possible to use the
> existing presence subscription protocol without changing anything?
> The result should be same as with a JEP-0033-like transfer of the
> context subscriber list before getting started with smarticasting.
> maybe a bit nicer to the network, as off hours are nicer. This also
> addresses database tweaks (how the hell do you gain access to the
> database if you're not the jabber admin?) if those tweaks would
> sooner or later be detected and end up in the jabber server log.
> We could extend the JEP in a way, that the presence database is
> kept clean by periodic updates during off-hours.
I guess the bigest servers (like jabber.org) which really matter here do
not have off-hours. Google talk servers probably would not have
> Concerning the privacy lists, we could extend the protocol used to
> define these privacy lists between client and server in a way that
> the changes are also forwarded to the target server, so the target
> server knows which exceptions to keep in mind. This also is a much
> less invasive change than to introduce a verbose new protocol.
You can never forward privacy list to other server. It is one of the
basic things of privacy list.
> | Well thats not up to you, the whole idea of privacy is that you can do
> | things that the other person does not know about, like blocking them.
> I noticed Jabber sends presence whenever someone is in the roster,
> then you have to put a filter to stop him from doing so. Other protocols
> let you keep somebody in the buddy list even if you haven't exchanged
> presence subscriptions.. easily, so you don't have to filter something
> afterwards. You can simply avoid handing out presence in the first place.
> I have understood that privacy filters is the only mechanism of this
> kind, and thus you cannot do without. It would be nicer if one could
> exchange "friendship" and roster listing without implying presence
> But this is just theory. Jabber has a model that relies on outgoing
> filters, so we will see how we can go about that.
You havent even read the specs, right? There is a whole page of tables
describing when a presence is sent and when isn't. You can have someone
in your roster without him even knowing about it. According to the
protocol, I can have someone in a roster, to which I send presences
without him having me in the roster. And so on.
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
Size: 189 bytes
Desc: not available
More information about the Standards