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" <[EMAIL PROTECTED]> 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 >> [EMAIL PROTECTED] >> http://mailman.jabber.org/listinfo/jdev > _______________________________________________ > jdev mailing list > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
