[JDEV] jabber extensions available for handling location information

Timothy Carpenter timbeau_hk at yahoo.co.uk
Tue Apr 1 18:54:36 CST 2003


Mattias,

You are hitting an issue I felt important in pub-sub some time ago - see
attached note from last year on this very topic.

Your desire to convey different or subsections should be controlled by the
namespace subscribed to.

So if your packet has
 
<status>at work</status>
<location>at desk</location>
<activity>damn hard project X</activity>
etc.

then HR may subscribe to your presence in total, but only be permissioned
for and so get just <status>...the project manager of task X should be
allowed to specify <activity>  as the only thing they care about and thus
put that in the namespace for their subscription, not caring if you are at
your desk or not as long as you are busy doing their tasks! (to be fair,
some PM's should only be able to ask "if <activity> =
projectsUnderMyAuthority"...)

About source JIDs? IMHO the component should be passing that on inside the
message as part of the data, not spoofing the packet...

brgds
Tim

On 25/11/2002 1:33 pm, "Timothy Carpenter" <timbeau_hk at yahoo.co.uk> wrote:

> I agree and disagree with both sides!
> 
> I agree that <location> can form part of <presence> - e.g. "I am on the
> phone at my desk" or "I am busy in meeting room 1" is a very natural
> combination.
> 
> However, pub/sub would be a natural vehicle to filter, distribute and direct
> the information delivery.
> 
> Thus, this problem domain is a pretty good 'test case' for pub/sub.
> 
> Why? Two main reasons.
> 
> 1) It tests issues such as namespaces. An hierarchical namespace would put
> strain on filters if the key interest is at a lower level in some agreed
> hierarchy. What comes first? Is it name.title.organisation.location.presence
> or location.title.name.presence.organisation or
> title.presence.organisation.location.person?...and this is only a few
> elements!
> 
> 2) It also reveals the need for a layer below the 'source' publishers - a
> need for intermediate collators and filters to provide an efficient,
> flexible service to subscribers.
> 
> As an example, a Client application should not have to perform an <iq> and
> lookup information before deciding what to do with <location> information
> (it should be able to request eg "any of my clients at reception" without
> having to receive all "at my desks" and perform the filtering). Equally, the
> <location> publisher should not get involved in how what when why people
> want to filter the information it is publishing, as that would, at a stroke,
> limit the uses of that information and burden the publisher.
> 
> An intermediate pub/sub component should perform the handling of the
> subscriptions which may cut cross many 'sources'.
> 
> Appologies if this hasty note is not as clear as it should be.
> 
> brgds
> Tim
> 
> 
> 
> On 25/11/2002 1:01 pm, "Ulrich Staudinger" <chicago5 at gmx.de> 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.
>> 
>> 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.
>> 
>> My four cents
>> 
>> ulrich
>> 
>> 
>>> 
>>>> beside this, it is definitely a cool project! :)
>>> 
>>> Sure thing!
>>> 
>>> --
>>> Greetz,
>>> 
>>> Ralphm
>>> _______________________________________________
>>> jdev mailing list
>>> jdev at jabber.org
>>> http://mailman.jabber.org/listinfo/jdev
>> _______________________________________________
>> jdev mailing list
>> jdev at jabber.org
>> http://mailman.jabber.org/listinfo/jdev
> 
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
>> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 




More information about the JDev mailing list