[Standards-JIG] proto-JEP: Flagging the Primary Resource

Ian Paterson ian.paterson at clientside.co.uk
Fri Sep 30 13:09:44 UTC 2005

> > What if the resource from which you last received 
> > presence is connected to the server via an intermittent
> > WAP connection (known to the server but not to the
> > subscribers) and the server never considers such a 
> > connection to be primary because of the connection type?
> Does my server really have any clue to decide which of my 
> resources is a primary one?
> Taking your example:
> - I have to resources connected. One direct and one WAP.
> I see two scenarios:
> - I'm sitting at my desk and would like to get messages on my 
> desktop client
> - I'm away of my desk doing something and would like to 
> recieve messages on my mobile
> Does my server really is in the position of deciding which 
> resource is my primary one at the moment? No. I have to tell 
> it explicitly. And that's what I have priority attached to 
> presence. Rising my priority while sitting at the desk and 
> lowering while walking away.

So in this case you're suggesting a solution something like this: WAP
clients could default to priority=20 all the time. Whereas desktop
clients could default to priority=30 when the user is available and 10
when the user is away?

> We are spending much time discussing situations when there 
> are many resources with the same priority. We're creating 
> workarounds, taking different aproach - show, time, name, 
> etc. when we have a solution already implemented and 
> deployed. While the reality is that the server is not in the 
> position, and really has no clue, of deciding where the user 
> really wants to get messages recieved. I think the situation, 
> when there are many resources with the same priority is 
> abnormal and shouldn't happen.

IMHO right now it is the normal situation. Aunt Tillie tends to let her
client choose the priority all the time (so do I BTW).

> "simple clients" - I'm whole 
> heart for the idea, but let's be real - there has to be at 
> least some logic there. :-) We cannot workaround all client 
> defeciencies in the servers.

More information about the Standards mailing list