[standards-jig] Presence priority finetuning

Julian Missig julian at jabber.org
Fri Jun 21 21:06:50 UTC 2002

On Fri, 2002-06-21 at 16:05, Sami Haahtinen wrote:
> On Fri, Jun 21, 2002 at 10:31:50AM -0400, Julian Missig wrote:
> > On Fri, 2002-06-21 at 03:24, Sami Haahtinen wrote:
> > > > How is that fundamentally worse than the client just declaring it? I
> > > > think it's better than the client sending a message to the server,
> > > > since clients will already be built to respond to feature negotiation
> > > > or browse requests from other clients... why not make the server ask
> > > > for that info as well?
> > > 
> > > i think the best way is for the client to somehow declare a priority for
> > > some message type, as in for pubsub with namespace foo priority is 99
> > > and with others it's -1 (is there such thing anymore?)
> > > 
> > > but then again, the client needs to somehow verify that the server also
> > > supports the priorities, so that the client is not connected in vain.
> > 
> > I'm still not seeing how that is fundamentally better than just having
> > the server ask the client...
> (lets just assume that we make up somekind of priority system for these)
> one client might want to declare that it wants all headlines, but
> doesn't want pubsub FOO, although it supports FOO.

Yeah, I thought that was the whole point of adding this additional

> it is much harder for the server make this decision for the client. if
> the client does not declare that it wants the traffic for something, it
> would be looked at like the clients are looked at now when they declare
> 0 priority.

See previous comment.

> ofcourse this could be done with the server probe too, but none of the
> current JEPs would be suitable for the job.. (well, none of them would
> be suitable for the other way either =)

Right, but I think that it's much simpler to add some sort of attribute
or element to declare that you would prefer to or prefer not to handle a
certain type of feature/namespace if you support it.

This way, other clients can even figure out if you would prefer to
receive certain namespaces. If the preferences are only declared when
sent to the server, clients are never even given the option of
overriding the server's priority logic intelligently. All they have to
do is browse/disco/feature negotiate/whatever we decide with the
user at server ID, they get the list of features supported by the various
clients *and* the data about what they prefer to handle is there as
well, allowing intelligent decision making when overriding the server.

If the preferences are only a part of some new protocol you use with the
server once, then clients don't have this option. And the lightweight
clients you keep trying to argue for now have to support a minimum of
*two* feature negotiation protocols rather than just generally
supporting the one that is decided upon.

The beauty of XML is that you can add an extra element/attribute or two
to the browse/disco/feature negotiate protocol that is decided upon
without breaking it. I don't see how creating a whole other protocol is
better than just doing that.

Just because the current JEPs don't do 100% of what you want doesn't
mean you should create yet another one. That's part of the reason we
have several pub/sub and browse/disco/whatever JEPs now. We need to
decide on something and go with it. The namespaces can be extended
beyond what the first JEP about them says...


More information about the Standards mailing list