[JDEV] jabber extensions available for handling location information

[Arjan Peddemors]

We had two main reasons for having the location element at the 
same level as the presence element. First, we are considering 
presence and location (and many other types of information) as
independent parameters that define the context of a user (or
other non-human entity).  Second, we want the user to control
the distribution of his/her context information in a flexible
manner: the user must be able to allow subscription to this
information an a per-item basis. This means that subscription
to presence and location, although essentially based on the
same mechanism, is completely independent.

In the end, this translated to having a top-level location
element. The location subscription mechanism is more or less
copy-past from the presence handling. I think, if there was
a generic and flexible publish/subscribe mechanism available as 
part of the jabber server at the time we started the development,
we would have used that (I didn't really follow the discussion
on what here is called pub/sub, but at first glance it looks 
promising).

thanks,
Arjan.

> -----Original Message-----
> From: Ralph Meijer [mailto:jabber.org at ralphm.ik.nu] 
> Sent: maandag 25 november 2002 15:00
> To: jdev at jabber.org
> Subject: Re: [JDEV] jabber extensions available for handling 
> location information
> 
> 
> 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
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>