-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/17/09 7:52 AM, Alexander Tsvyashchenko wrote: > Hello Remko, > > On Thu, 17 Sep 2009 14:08:03 +0200, Remko Tronçon <[email protected]> > wrote: > >> I don't think I agree: I'm still convinced resources should be treated >> as opaque strings. Historically, clients filled in hostnames, or >> worse, ask the user to provide his resource name, but nothing prevents >> servers to auto-assign resource names (GTalk does this up to a point, >> but many users don't even provide resource names and let the server >> choose one) >> >> The fact that you want to look for a conversation while talking to >> someone when she was at work should not be done by searching for a >> specific resource (who says that I call my work resource "Work", and >> not "Acme", or "Werk", or ...), but by using other meta-information >> (e.g. geoloc, client version, ...). I don't think a resource is to be >> considered part of a conversation, just a low-level routing detail. > > Well, I do not think I fully agree with your disagreement ;-) > > I agree that the preferred way to determine user location is using the > extension that > was specifically designed for this purpose, as well as in general that > using specialized > extensions for any other information that might be conveyed in resources > is "the right way" (tm). > Then using resources for the same purposes covered by specialized > extensions is indeed irrelevant. > > However, it doesn't look like all (or even majority) of clients support > all necessary extensions > and all (or even majority) of users have them configured properly, right? > > On the other hand, using resource for the same purposes works right here > and now - at least > for those who care to use it like that, and in my experience that's bigger > number of people than > those using extensions like "user location". > > Anyway, that brings us slightly off-topic, because XEP-136 does not > support user location > storage/retrieval/matching anyway, so resource currently is the only way > to provide similar functionality. > > That brings an interesting question: should XEP-136 provide some way of > recording user location > (and, probably, some other additional information?) when storing the > collection? > > There's already <x> element support to attach additional data to > collection, but it is too generic > for this purpose, it's allowed to have only one <x> element and there's no > way of doing any kind of > matching/retrieval based on it. > > Probably matching/retrieval should be handled via search, though? >
Can't we just use the <note/> element? http://xmpp.org/extensions/xep-0136.html#collections-note The problem is that you don't know at the time what might trigger a memory ("oh yes, she was at work then so I'll search for conversation marked 'work', but I never mark things at the time so I'm out of luck"). I think this is the kind of problem that humans are good at solving through the flexible application of intelligence, and that technical solutions (tagging or semantic markup or whatever) simply won't get us where we need to go. As far as I can see, the Semantic Web hasn't exactly taken off. My hopes for Semantic Jabber are no higher. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqz0S0ACgkQNL8k5A2w/vyKggCfRMt8D9C1IjMYMel1zuPTGmLp PAsAn057DuTtSt3NepjFcCZr+45lMqvL =MxTh -----END PGP SIGNATURE-----
