Re: [Telepathy] Account and AccountManager objects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 29 Jan 2008 at 13:41:47 +, Simon McVittie wrote:
org.freedesktop.Telepathy.AccountManager.Interface.Conditions
=
[...]
Signals
---
AccountRequirementsUpdated (as: Provided, as: Not_Provided)
Should be AccountConditionsUpdated of course, and this whole interface
could probably do with some renaming to make it less confusable with the
corresponding interfaces on Preset and Account.
org.freedesktop.Telepathy.AccountManager.Preset
===
[...]
D-Bus core Properties
-
[...]
Conditions: (as (Account_Condition[]), read-only)
Conditions that accounts using this preset should have by default.
I think this property is sufficiently contentious that it should be in a
separate interface o.fd.T.AccountManager.Preset.Interface.Conditions
or something, so we can swap it out if it turns out to have been a poor design.
org.freedesktop.Telepathy.Account
=
I think DesiredStatus needs revisiting when I've worked out what account
status notification will look like.
The exact semantics of AutoConnect and DesiredStatus will have to depend on the
Conditions interface, but I think they're probably uncontroversial
enough that if we later replace Conditions with something else, we can
define AutoConnect and DesiredStatus in quite a vague way, and have
Conditions and Conditions2 each describe their own exact semantics in terms of
AutoConnect and DesiredStatus.
However, at least Conditions (probably better named RequiredConditions) should
be on a separate interface, o.fd.T.Account.Interface.Conditions, since I'm
unsure about this API and we may well want to replace it in future...
Signals
---
AccountPropertiesChanged (a{sv}: Delta)
... which would mean that this signal (as described) would not be emitted if
the required conditions changed, because it would not be on this interface.
Obviously this would mean that the Conditions interface needs a
RequiredConditionsChanged signal.
Simon
-BEGIN PGP SIGNATURE-
iD8DBQFHoFmJWSc8zVUw7HYRAu9aAKCeXMf4Bx208Dyp8OKZxaBwq0nSTwCgzLrj
ZaoHTjjH4rQtfWuzFDnUWmY=
=C3Hj
-END PGP SIGNATURE-
___
Telepathy mailing list
Telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] straw man location API
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Simon McVittie Sent: Tuesday, January 29, 2008 4:09 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] straw man location API -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 29 Jan 2008 at 15:42:37 +0200, [EMAIL PROTECTED] wrote: GeoClue have made an unwieldy API for it with rigid flat structures and bit flags, Win32 style :-/ There's nothing wrong with bitfield flags - Telepathy has lots of them. They're an efficient way to transfer, well, sets of flags. When flags designate which other fields of the structure have valid data, that's what I refer to as Win32-ness. It's a lot like doing variant types by hand, and it doesn't really win much compared to general D-Bus overhead. A matter of taste, probably. I don't like some of their API (human-readable strings over D-Bus? erm... are the backends expected to be localized?... and, as you say, their civic location structs are rather rigid) but it's better than inventing our own *again*. Have you brought up your concerns with the GeoClue people? I was going to, and I probably will soon. As for civic location strings, let's suppose for sanity sake that only the data source does any possible localization. It's probably the only way with most location databases of the day. I still maintain that unless GeoClue is so terrible that we consider it a complete dead-end (and IMO that's not true), the way forward is for people interested in Telepathy+geoloc to treat them as the Telepathy of geolocation and use their formats by reference; and if their formats are crap, help them to fix that before they freeze D-Bus API. I've briefly reviewed their new design proposal, and it looked like they design for a single daemon providing the device's location data. I should recheck, but I believe there are no data types defined for locations to pass around. There is also some minor ugliness in the D-Bus APIs, like passing three separate arrays of the same size where an array of structures would seem logical. -- Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Account and AccountManager objects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 30 Jan 2008 at 14:39:13 +0200, Alberto Mardegan wrote:
ext Simon McVittie wrote:
OK, here's an API sketch.
BTW, I always forgot to
mention that connectivity information provided by connectivity plugins
could also affect the account parameters: for instance, the SIP CM
accepts a local-ip-address parameter. We could make it so that if the
connectivity parameter's name matches a protocol parameter, then it's
passed to the CM. Slightly hackish, but cannot think of anything better ATM.
It's unclear to me what the requirements are here. Is the goal that we
tunnel all the SIP RTP streams through whatever VPN is available, or what?
This is somewhat reminiscent of the special cases MC currently has for
setting up HTTP/HTTPS proxies using configuration from gconf.
With this sort of thing in mind, we definitely want conditions and so on to
be an add-on interface! We can replicate the functionality of the current MC
without them, so if necessary we can put them to one side, define the
core interface somewhat vaguely (do foo if possible), and come back
to them.
org.freedesktop.Telepathy.AccountManager.Preset
Anyway, if we want to expose the presets on DBus, we also need a method
to list them.
Yeah, obviously.
Should MC support arbitrary (namespaced) key/value attributes, which it
doesn't understand but can just pass through?
Yes. Sticking to .desktop-style files, I'd allow them to have arbitrary
[sections].
I think we should make an obvious distinction between things that are
expected to change MC's behaviour, and things that are just client stuff.
This is particularly important if profiles/presets are on D-Bus. Perhaps
we should stick to files for the moment, and move to D-Bus if there's a
need for centralized inotify'ing.
Locale: s
[EMAIL PROTECTED], or /C/POSIX (all equivalent)
I don't understand the meaning of the Locale type.
It's a locale (loosely: language environment) into which apps can be
localized. For instance en (English), en_US (USA English), pt_BR.UTF-8
(Brazilian Portugese with UTF-8 encoding).
This is a straightforward mapping of .desktop localization into the
D-Bus interface. Locales like this are also the languages that
gettext() will choose between, if you choose to use it.
org.freedesktop.Telepathy.Account
=
[...]
DesiredStatus: (uss), read/write
A struct (Connection_Presence_Type, CM-specific presence status, message)
indicating what status we'll want if we put this account online.
As a special case, hidden indicates hidden if possible, else busy,
while offline indicates hidden if possible, else offline.
Mmm... what is Connection_Presence_type?
It's the enumerated type from the Telepathy spec that contains Unset, Offline,
Available, Busy, Away etc. See:
http://telepathy.freedesktop.org/spec.html#type-Connection_Presence_Type
BTW, I see that you moved most of the data into properties. Seems fine
to me, but I have never used them and I'd like to be assured that they
also emit signals when their value changes, and that these signals carry
the new value (I couldn't find any mention to property signals in the
DBus specs).
The D-Bus core Properties interface doesn't include any change notification,
but that's why I put property change notification on the TODO list. I'd
probably add a signal per interface like this:
AccountPropertiesChanged (a{sv}: New_Values)
Properties from the Account interface may have changed. New_Values
is a map from property names to values; it contains at least the
properties that have changed, and MAY contain unchanged properties.
D-Bus core Properties are namespaced by interface names; the Properties
interface is very simple, containing three methods (Get and Set, which do
what you expect, and GetAll, which gets all the properties of a
specified interface). So the calling sequence would be:
connect to o.fd.Telepathy.Account.AccountPropertiesChanged
call o.fd.DBus.Properties.GetAll(o.fd.Telepathy.Account)
connect to o.fd.Telepathy.Account.Interface.Extra.ExtraPropertiesChanged
call o.fd.DBus.Properties.GetAll(o.fd.Telepathy.Account.Interface.Extra)
... and so on ...
Simon
-BEGIN PGP SIGNATURE-
iD8DBQFHoHb1WSc8zVUw7HYRAlVeAKCuyZL6p2W1J0ayb2qPTnmZ8wbawwCgyz3d
I5SJfEiGLWAdrrkGrrcm9K0=
=9mi8
-END PGP SIGNATURE-
___
Telepathy mailing list
Telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] [Bug 13927] Account request for Alban Crequy
http://bugs.freedesktop.org/show_bug.cgi?id=13927 Benjamin Close [EMAIL PROTECTED] changed: What|Removed |Added Keywords||NEEDINFO --- Comment #3 from Benjamin Close [EMAIL PROTECTED] 2008-01-30 06:17:08 PST --- Can anyone confirm this request? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-salut 0.2.2 released
Hi everyone, I've just released telepathy-salut 0.2.2. This new release in the 0.2 stable branch fix few issues in the Clique protocol and tubes code. Most of this bug were discovered thanks to hyperactivity, a collaboration stress testing tool we are developing for the OLPC project. Tarballs available at: http://telepathy.freedesktop.org/releases/telepathy-salut/ Full changes below. G. Wed Jan 30 12:54:25 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] * version 0.2.2 Wed Jan 30 12:45:48 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] tagged telepathy-salut 0.2.2 Wed Jan 30 12:44:20 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] * version 0.2.2 Tue Jan 29 12:51:58 CET 2008 Sjoerd Simons [EMAIL PROTECTED] * GibberRMulticastTransport: Flush the state when asked to disconnect Mon Jan 28 14:55:46 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] * salut_params_free: don't leak the published-name Mon Dec 17 14:57:50 CET 2007 Guillaume Desmottes [EMAIL PROTECTED] * salut-bytestream-manager: don't leak our streaminit_reply_cb_data structure if the XMPP connection failed Fri Jan 25 14:17:13 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] * salut-contact: fix leaks when setting olpc_ip4 and olpc_ip6 value Fri Jan 25 13:38:50 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] * bytestream-manager: fix a muc-manager refcount leak leading to a vicious crash when disposing connection Fri Jan 18 11:50:09 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] * salut-self: send_olpc_activity_properties_changes_msg: convert GError to a TP_ERROR Fri Jan 18 11:42:44 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] * salut-self: update_activity_privacy: convert GError to a TP_ERROR Fri Jan 18 11:34:38 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] * salut-self: update_activity_privacy have to be static Thu Jan 17 15:51:45 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] * gibber-r-multicast-causal-transport.c: fix a crasher when a transport is disconnected before the self sender was created Thu Jan 10 14:53:38 CET 2008 Guillaume Desmottes [EMAIL PROTECTED] * salut-connection: don't create the bytestream mgr if something got wrong and we disconnected the connection Tue Jan 8 16:30:41 CET 2008 Sjoerd Simons [EMAIL PROTECTED] * version 0.2.1.1 Tue Jan 8 16:25:24 CET 2008 Sjoerd Simons [EMAIL PROTECTED] tagged telepathy-salut 0.2.1 ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] straw man location API
Ar 29/01/2008 am 15:42, ysgrifennodd [EMAIL PROTECTED]: Should there be more detail in the location data type? Maybe, just documented dictionary key names would do. Location data, especially the civic address, tend to be hairy with many fields unset, and some fields overlapping in meaning with others (e.g. a blob address string vs detailed fields). GeoClue have made an unwieldy API for it with rigid flat structures and bit flags, Win32 style :-/ Indeed. For my experiments, I only used lat/long as floating degrees. -- Dafydd ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
