[JDEV] jabber extensions available for handling location information

[Ralph Meijer]

On Mon, Nov 25, 2002 at 02:01:03PM +0100, Ulrich Staudinger wrote:
> Ralph Meijer wrote:
> > 
> > On Mon, Nov 25, 2002 at 01:18:15PM +0100, Ulrich Staudinger wrote:
> > > I agree, another top-level element is not very hany and somehow disrupts
> > > the order in xmpp. I suggest to set up a jep about this and putting
> > > <location> in presence.
> > 
> > IMHO (again) this context information doesn't belong in the presence stanzas.
> > Not everybody wants to receive this information, and the gabber hack for
> > conveying music information is not nice either, in retro-spect. Again:
> > publish/subscribe.
> 
> IMHO i think pubsub doesn't suit this scenario. There exist many
> scenarios for Pubsub, but this scenario, calls for some sort of presence
> enhancement, since the location of a person is an elemental part of
> his/her physical presence in a room. Of course i agree, the gabber hack
> isn't very polite either. 

I'm not sure what the argument here is, but generally speaking (i.e. not
this specific application) I would not consider the location of a person
to be an elemental part of presence. Presence, in jabber, tells you
if this person wants to receive messages and can be disturbed. Sure,
in most cases it seems logical that the jabber entity is online to
send location information, but why does he have to send presence.

Think of this application: someone, not having an always-on device, is
traveling and sometimes wants his location on a Jabber enabled Map to be
updated. He could use a very small client that just publishes this information,
but not sending presence, because he has no time/money to chat.

> Another argument against pubsub (in this case) is integrity. The
> integrity of users and clients in this environment and in this scenario
> is based upon the acceptance of a location element, transmitted in some
> way. All users can only benefit from this system if a user doesn't have
> to willingly subscribe to such a location tag. 

I think most end-users are not interested in having location information
flowing to their client on every update (say every minute) of everybody on
their roster. I would rate it as waste of bandwidth. What would be interesting
is to be able to retrieve the last known location. This would for example be
integrated in the user details view of a GUI client. Being able to retrieve
the last published item in pub/sub is among the requirements for the protocol.

For mobile clients on the other hand, you might want to have this information
sent to you on every update. And of course a mapping application needs this
information on every update, too.

My point is: only send the information where it is needed. If you have a client
that uses location information: let the application subscribe to that
information for everybody in the roster. You could even do this server side,
the same as with presence: you have to send presence to receive it from others.

> My four cents

Ooh, expensive!

-- 
Greetz,

Ralphm