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? -- Good luck! Alexander
