Re: [Telepathy] Rich presence
Ar 05/12/2007 am 13:50, ysgrifennodd [EMAIL PROTECTED]: PIDF-LO is an extension to PIDF, described in RFC 4119. Its usage for practical purposes (what do you want, it's IETF) is further clarified by this draft: http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile It can express what XEP 80 does and more. There are interesting locations like arc bands and rectangles/prisms, which cannot be boiled down to a point-accuracy ellipsoid without losing information. Also, it takes care to specify units and the coordinate system, which go by silent assumption elsewhere. I thought XEP 80 was complicated enough. :P I was planning to restrict the API to using WGS 84 for geographical coordinates. This implies that clients and connection managers may need to do conversion in some cases. I think having a latitute/longitude in WGS 84 covers the majority of use cases. Further use cases are probably covered by having room/street/city/province/country etc. key/value pairs. For more complicated cases, using extended presence or tubes may be more appropriate. -- Dafydd ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Rich presence
[EMAIL PROTECTED] wrote: I agree, it's good enough to cover most of implementations, (if you throw in altitude and horizontal/vertical accuracy). Now the question is, do we want it as special key names in the dictionary, or a specialized interface (or even GeoClue API infusion) will be a better approach. The approach we were taking was to add a GeoLocation interface to the Connection object. For the same reasons that the XMPP community has created PEP for rich presence features, I'm concerned about bloating the Telepathy presence definition (even worse than it currently is, although tp-glib defines a simple presence interface for CMs which we're likely to move into the spec at some point) with information beyond a status, message and last idle time. Accordingly, stuff like mood, location and currently playing song should be added in specific interfaces for those functions. Best regards, Mikhail Regards, Rob ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Rich presence
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Dafydd Harries Sent: Wednesday, December 05, 2007 2:35 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Rich presence I was planning to restrict the API to using WGS 84 for geographical coordinates. This implies that clients and connection managers may need to do conversion in some cases. I think having a latitute/longitude in WGS 84 covers the majority of use cases. Further use cases are probably covered by having room/street/city/province/country etc. key/value pairs. I agree, it's good enough to cover most of implementations, (if you throw in altitude and horizontal/vertical accuracy). Now the question is, do we want it as special key names in the dictionary, or a specialized interface (or even GeoClue API infusion) will be a better approach. Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Rich presence
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Dafydd Harries Sent: Tuesday, December 04, 2007 7:05 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] Rich presence Ar 04/12/2007 am 16:51, ysgrifennodd [EMAIL PROTECTED]: Hi, I'd like to have a discussion on extended presence support in Telepathy. In the current spec, there is a freeform map of presence parameters to arbitrary values, and it's not specified what these parameters and values might in principle carry, or will there be some parameter names with a particular meaning commonly interpreted by Telepathy clients. In order to support things like geospatial or civic location as part of contact's presence information, I think we ought to have some common naming conventions and/or data types for corresponding parameters. Specifially in case of geolocation, this is not helped by the fact that presence information is represented differently in various network protocols (e.g. PIDF-LO in SIP and XEP-0080 in XMPP), the GeoClue framework will have its own representation, and all of these except PIDF-LO are really naïve in what kinds of location they can represent (most settle for a GPS-derived latitude-longitude-accuracy tuple, forgetting to specify such trivial matters as the reference geoid). Any ideas? I've written a location interface loosely based on XEP 80 (dictionary with standardised key names). I'm not really familiar with PIDF-LO. PIDF-LO is an extension to PIDF, described in RFC 4119. Its usage for practical purposes (what do you want, it's IETF) is further clarified by this draft: http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile It can express what XEP 80 does and more. There are interesting locations like arc bands and rectangles/prisms, which cannot be boiled down to a point-accuracy ellipsoid without losing information. Also, it takes care to specify units and the coordinate system, which go by silent assumption elsewhere. I also implemented the interface in Gabble. I'll try and put up a spec patch soon. Great, I'm looking forward to see it. BR, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
