Re: [Telepathy] Account and AccountManager objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please mostly ignore things that are *missing* in my spec, and focus on things that are *wrong*... we can add missing functionality easily, but removing broken functionality from the core interfaces is hard. On Fri, 08 Feb 2008 at 17:46:53 +0200, Alberto Mardegan wrote: ext Simon McVittie wrote: OK, I'll make RequestedPresence a separate r/w property. I honestly don't see the use-case though - could you explain what critical thing I'm missing? A presence applet might want to show what presence we are going online with -- sometimes it might be different from the AutomaticPresence. patch-20 and patch-21 in monkey. PresetParameters is not the parameters from a .preset, it's all the parameters that are pre-set. The AM API doesn't care where they came from, only that they exist and have whatever values. But since they can be dynamic, what should happen when you try to read this property? You tell me! See below... I'm not sure how this provisioning stuff could sensibly interact with account-editing UI - do you have any thoughts on this? I'm not sure it would interact with the UI. Provisioning might consist of a URL (for accessing which you might need an authentication, such as username and password) which you connect to, and the URL returns (maybe in XML form) all the account parameters you need to connect to the service. Then, you might want to store them into the account parameters, or maybe not. So, it could be external to the account-editing UI. Suppose we support provisioning for SIP accounts from a provider (let's call them Gozmi :-), which sets the 'proxy-url', 'tls-badgers' and 'bong-hits' properties correctly to whatever the Gozmi sysadmins want you to use this week, by doing some sort of buzzword-enabled-XML-RPC. Suppose also that the SIP UI has an advanced options tab, containing 'proxy-url', 'tls-badgers' and 'bong-hits' properties. I click on my Gozmi account and go to the advanced options tab. What do I see in the 'proxy-url' box, and where did it come from? ... then there's your answer to the previous question :-) If ConnectionHandler (or in-process equivalent) is allowed to fill in required parameters, this also has implications for the Valid property; the AM would need to know which parameters would be provided by the connection handler, so it could mark accounts as valid even if e.g. the password was missing. The account creation UI would also need to know that it was OK for the password to be missing if a connection handler was able to fill it in - so in practice there'd probably need to be some sort of Account.Interface.Dynamic going on anyway, so the account creation UI could query it and find out what it was OK to omit. Alternatively, password-querying and provisioning could move into the CM. For passwords, the CM would behave as it does currently, unless a UI process has first told it I am willing to ask the user for passwords on your behalf, emit a signal when you want me to, in which case it would ask the UI process for help (while still in the CONNECTING state) for as long as that process was on the bus. We'll probably need to do something similar for TLS is this certificate OK? policy at some point anyway. For provisioning, the provisioning URL could just be one of the parameters (I assume it's only SIP that's labyrinthine enough to need provisioning - with e.g. XMPP you can just say I'm [EMAIL PROTECTED] and here is my password and auto-detect everything from SRV and in-band negotiation, at least in principle). Mmmm... Quoting you: there's no point in me designing a wonderfully clean API if it turns out not to be implementable in half the bindings!. :-) I've now implemented a D-Bus core Properties mixin for telepathy-glib, with a simple regression test. It doesn't show up in the output of Introspect() due to dbus-glib limitations, but I can probably fix those in dbus-glib sometime, and that's not critical functionality. Following some discussion on the D-Bus list, I have a better idea of what's interoperable. It turns out most of the problems with properties were unique to dbus-glib, so the way I was using them in the spec is indeed entirely reasonable. Simon -BEGIN PGP SIGNATURE- iD8DBQFHtGO6WSc8zVUw7HYRAvqDAKCMxYKwq5HyqgPNk+74AgO4uvPqaQCg8PRy AvoXZhJoNOdMYKrZo7Rm98w= =rb4q -END PGP SIGNATURE- ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Account and AccountManager objects
Hi! Some comments about Simon's proposed accounts API, to be found at: http://people.collabora.co.uk/~smcv/accountmanager.html#org.freedesktop.Telepathy.AccountManager - About RequestPresence: If we expect clients to care about changes to the requested presence YES WE DO! :-) - Groups/tags: as they were in Zdra's proposal, the API was quite simple that IMHO it doesn't require a separate interface. I would just add them to the basic Account interface. - Also, SetPresenceOnGroup might be useful. - The FindAccounts API as it was in Zdra's proposal is extremely useful for clients, I would add it now. - About the account parameters: To get the complete arguments to RequestConnection, clients must also look at the PresetParameters property. and Clients can obtain the mapping that would be passed to RequestConnection by taking a copy of the PresetParameters property, then merging in the values from the Parameters property, overwriting existing values if necessary. are both going to be wrong. We already have in NMC the possibility to compile in some provisioning plugins to provide the account parameters on the fly; so, for this new API, at some time we will want to specify an API for parameter plugins to provide the account parameters (all of them, of just a few to be merged); these could be the password (for a GUI plugin), some connectivity parameters (IP address or other networking hints) or just any parameter. - As I read the IRC logs, Robert was proposing to have a separate interface for that part of the API that makes sense only for the valid accounts; I don't have an opinion about that, but I have an opinion that RequestPresence and RequestChannel (together with all the relevant properties and signals) should be together in a same interface. BTW, I didn't find any documentation about DBus object properties, other than a mention to a exported_properties field in the DBusGObjectInfo structure. How do they work? Does dbus-glib automatically exposes those GObject properties that are listed in the exported_properties field? Ciao, Alberto -- http://www.mardy.it -- Geek in un lingua international! ___ 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 Fri, 08 Feb 2008 at 09:59:48 +0200, Alberto Mardegan wrote: - About RequestPresence: If we expect clients to care about changes to the requested presence YES WE DO! :-) OK, I'll make RequestedPresence a separate r/w property. I honestly don't see the use-case though - could you explain what critical thing I'm missing? - Groups/tags: as they were in Zdra's proposal, the API was quite simple that IMHO it doesn't require a separate interface. I would just add them to the basic Account interface. These are sufficiently contentious that we want them in a seperate interface, so we can jettison them and replace with something different if it turns out we did them wrong. The core interface is the one we can't get rid of (easily, anyway), so it should be relatively minimal. - Also, SetPresenceOnGroup might be useful. ... obviously, the group interface must have this. - The FindAccounts API as it was in Zdra's proposal is extremely useful for clients, I would add it now. I'll look at the proposed API and see what I think. Possibly an extra interface again, if I'm not convinced we'll want to keep it forever. - About the account parameters: To get the complete arguments to RequestConnection, clients must also look at the PresetParameters property. and Clients can obtain the mapping that would be passed to RequestConnection by taking a copy of the PresetParameters property, then merging in the values from the Parameters property, overwriting existing values if necessary. are both going to be wrong. We already have in NMC the possibility to compile in some provisioning plugins to provide the account parameters on the fly; so, for this new API, at some time we will want to specify an API for parameter plugins to provide the account parameters (all of them, of just a few to be merged); these could be the password (for a GUI plugin), some connectivity parameters (IP address or other networking hints) or just any parameter. PresetParameters is not the parameters from a .preset, it's all the parameters that are pre-set. The AM API doesn't care where they came from, only that they exist and have whatever values. The only point of exposing these at all is to let account-editing UIs display them as defaults, instead of falsely claiming that the values from the .manager file/the CM will be used. I'm not sure how this provisioning stuff could sensibly interact with account-editing UI - do you have any thoughts on this? - As I read the IRC logs, Robert was proposing to have a separate interface for that part of the API that makes sense only for the valid accounts; I don't have an opinion about that, but I have an opinion that RequestPresence and RequestChannel (together with all the relevant properties and signals) should be together in a same interface. Rob and I don't think RequestChannel should be in the AM. It's conceptually closer to handling incoming channels, in the (as yet unwritten) channel dispatcher API. BTW, I didn't find any documentation about DBus object properties, other than a mention to a exported_properties field in the DBusGObjectInfo structure. How do they work? Does dbus-glib automatically exposes those GObject properties that are listed in the exported_properties field? dbus-glib implements them badly (see recent discussion on the D-Bus mailing list, and conversation starting with me going epic, epic failure on #telepathy). I'm going to have to do some hacking on either telepathy-glib or dbus-glib before we can usefully use them. For now, rather than implementing new APIs, would you mind concentrating on porting MC (at least client API) to use telepathy-glib TpChannel etc., with libtelepathy TpChan etc. only appearing for backwards compatibility? Please send me any patches you want reviewed. Simon -BEGIN PGP SIGNATURE- iD8DBQFHrFvfWSc8zVUw7HYRAltfAJ47f5r9S6CAQ1zF0PBAeZpguHVx/QCdEDec CJdO31RtTIs7XQbWWZr2iXk= =hpaB -END PGP SIGNATURE- ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Account and AccountManager objects
Hi,
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
ext Simon McVittie
Sent: Tuesday, January 29, 2008 3:42 PM
To: telepathy@lists.freedesktop.org
Subject: Re: [Telepathy] Account and AccountManager objects
Account_Condition: s
A condition that might be required for an account to be available.
These may be any UTF-8 string, but they SHOULD be short
strings of ASCII
letters, digits, hyphen/minus characters and dots, starting
with a letter
or digit.
All conditions not containing a dot are reserved for the Telepathy
specification. Third-party conditions SHOULD be namespaced
by a reversed
domain name, e.g. com.example.vpn-enabled.head-office.
A string with certain conventions is good enough, but I think there are two
attributes to every condition that might be worthy to separate. One is the
condition type, that could tell a client that this condition is their domain.
Another is the unique tag as such (within the type namespace). For example,
{org.whatever.vpn, MyOfficeVPNAccount}.
It's similar to detailed GObject signals, or XML namespaces.
I think a (type, name) condition tuple could be more convenient than a
syntactic convention on the single ID string, that the clients would have to
parse in order to filter conditions interesting to them.
My two cents,
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 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] 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
Re: [Telepathy] Account and AccountManager objects
ext Simon McVittie wrote: So whatever UI causes the activation is responsible for deciding what status to set? That sounds rather mysterious... it sounds like a job for MC really. On the other hand, I suppose the UI might ask the user? - |To call Bob, you need to connect to the account | |Google Talk ([EMAIL PROTECTED]).| | | |Set this status: [ (-) Busy |v] | |with message:[On the phone__] | | | | [ OK ] [ Cancel ] | - In theory -- but I hope that in practice the UIs won't bother the user with such questions. :-) Thinking about this some more, here are ways an account can become connected, and possible things we could do: * We gain an Internet connection, or do some other action that can trigger an onlineness event. Accounts that are so configured try to go online. Requirements to support this: either MC guesses an appropriate status for all accounts (in ITOS2008 it's a global preference), or each account has a stored value for when you get online, do this. Reasonable implementation: for each account, either store a boolean put this online whenever possible, or a presence type (possibly Offline) set this status whenever possible (I was leaning towards the latter in previous mails) I vote for presence type, +message (not that I find the message that important, but it doesn't cost much to add it now). * The user asks to initiate a call/IM session/... with a stored contact. That account has to go online first. Requirements to support this: either MC guesses an appropriate status for the account, or it uses the stored status from the previous case Reasonable implementation: the UI sketch above seems OK, actually. The UI could always ask MC what status would *you* set?, or perhaps pass in Connection_Presence_Type_Unset to trigger an MC decision, if it doesn't want to ask the user. I think that going online with the same presence (+message) we talked about above is the simplest and most coherent solution. Of course the UI can choose to give the user the possibility of setting another presence (but if I were a user I would be quite annoyed by that), either by changing the default presence for the account, or by forcibly request that presence, wait for the account to connect, and then call RequestChannel. * The same as the last one, but we weren't previously connected to a network, and we activate the network connection for the purpose (this is mostly an Internet-tablet case). Reasonable implementation: either we somehow freeze automatic connection for a short time, or we reason well, while they're going online anyway... and do the same as any other gaining an Internet connection event MC will have plugins for requesting connectivity. * The user explicitly asks to put this account online (implicitly selecting a status) * The user explicitly asks to put a group that includes this account, or all accounts, online (should probably be exactly the same as the previous) For the VPN use-case, we could have something in the Advanced tab of account config, I suppose: || | This account requires | | [ VPN vpn.example.com|v] | - -- together with some way for VPN plugins, etc. to add extra requirements. Yes. More about this on the next email. :-) Ciao, Alberto -- http://www.mardy.it -- Geek in un lingua international! ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Account and AccountManager objects
ext Simon McVittie wrote:
b: Able to connect
[...]
I agree on all this, but I would also add a separate flag for the cases
described in the latter paragraph: the UI needs to know that there is
something with the account that has to be fixed. So, an able to
connect flag to indicate whether the account can be connected now, and
another flag that says that the account is wrong/incomplete/the CM is
not installed/etc., which are all things fixable by the user.
Instead of a boolean, this might make more sense as a list of unmet
requirements, where an empty list means is OK.
(Obviously, we could choose to optimize this list into a bitfield ... or not.
Whichever makes more sense.)
I love bitfields, they remind me of my DNA. ;-)
I suggest to call the tags rather than groups (I mean the
user-assigned ones). We might want to specify some well-known tags, such
as work, home, toilet ;-), but still leave the possibility to
different clients to group them with different criteria.
Ah, here's where it gets interesting...
If the terminology is tags, an account can obviously have multiple tags.
If the terminology is groups, it's unclear. We shouldn't call this
concept tags unless we're prepared to commit to supporting many of
them (which perhaps we should be... I could be persuaded.)
I'm assuming that these tags or groups will be arbitrary strings assigned by
the user - we could suggest work or home, but they're free to use
whatever.
Yes, I think this was also Xavier's initial idea.
for instance
the account [EMAIL PROTECTED] could have these requirements:
{ ip-route: True, ap-name: work AP }
Whoa, whoa. ip-route there is clearly a technical requirement (Gabble
*needs* IP), but ap-name looks more like a user preference (you don't *want*
this account to auto-connect unless you're at work). Contradicting your
next paragraph:
An account with no requirements would be able to connect anytime.
I wouldn't mix the requirements (IP connectivity, availability of a
phone line, bluetooth, VPN,...) with the user preferences about when to
connect, which seems to be more fit for a UI: if the user doesn't want
to connect the gnome-phone-manager he can either disable the bluetooth,
or set the preferred connection status of that account to offline.
My ideas were not clear enough to be expressed properly. :-) What I
meant was basically that the set of requirement to be met for an account
to be able to connect should not include any logic about how or when to
connect, but just state a list of conditions to be met: if all those
match, then the account can attempt to connect.
[...]
On the other hand, assuming CMs declare their own technical requirements
somehow (either automatically, or just by MC knowing that e.g. the
protocol 'local-xmpp' never needs an Internet connection), we won't really
be able to address the I only use this when I have a VPN use case in
an automated way - only the user's third-party VPN GUI addon knows what
VPNs are available, and only the user knows which accounts are VPN-only.
Unless you're suggesting that the VPN GUI tells MC to add a
user-settable tag for each configured VPN, called something like connect
automatically when vpn.example.com is up?
Urgh, this is tricky...
Let's split it (I guess you also meant it, but just to make it clear):
not connect automatically when vpn.example.com is up, but this
account can be connected only if vpn.example.com is up, which, combined
to the default presence setting you mentioned in the other mail, would
in fact allow to realize a behaviour like connect automatically when
vpn.example.com is up.
So, summing up:
1) flag connect automatically when account connectivity is available
2) presence (+message) to be set when connecting
3) list of dictionaries with the conditions to be met to fire up the
connectivity available event for the account
If (1) is False, then (2) is ignored in this context; but it's still
used when the user requests a channel when the account is offline.
The contents of the dictionaries in (3) are mostly up to the
connectivity plugins and the account-editing UI, though in the specs we
definitely want to list some well-know values.
Also, this connectivity requirements should be allowed to be split in
the .manager files, .presets and in the account settings, and the result
should be the sum of all those requirements. For instance, a condition
like ip-route belongs to the gabble CM, while the condition on the VPN
could be in a .presets file and the access point is something that
definitely belongs to the account (advanced) settings.
It's taking a lovely shape ;-)
Ciao,
Alberto
--
http://www.mardy.it -- Geek in un lingua international!
___
Telepathy mailing list
Telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Account and AccountManager objects
ext Simon McVittie wrote: Presets consist of: * the connection manager to use * the protocol * an internal preset name, not for UI (either globally unique or unique per (CM, protocol) pair), e.g. gtalk I think it would be easier to have them globally unique, and residing in the same directory -- but I'm not going to have a strong opinion about this. * capability info - e.g. we know ahead of time that all GTalk accounts have the same server features - we can use this to pre-seed the Account's capabilities - CM protocol implementations have this too, though Makes sense, but we might want to keep it for later, as it's more like an optimisation. [...] Presets should perhaps be exposed as read-only D-Bus objects by MC. I don't think it would be beneficial, IMHO there's nothing wrong with applications reading the profiles themselves (or maybe we can provide that functionality in a client library). I don't see the advantage of using DBus here. Nokia MC on the Internet Tablets has some extra info, but some of that should be provided out of band by the UIs (e.g. accounts-plugin-gabble knows how to handle gtalk specially, but that's between it and the accounts UI). Yes. Account === [...] u (Connection_Presence_Type): Desired status The status MC is or should be trying to achieve *when this account is able to connect*. What are the possible values for this? Just online/offline? May be set to Offline by the user, to disable accounts. I guess you mean ...to disable accounts from connecting automatically. If you call methods to set this, MC acts on it, but only if the account is able to connect. (Rationale: if we define this to be when able to connect, we don't have to change it in response to network connectivity - MC can use some other mechanism to know which accounts can connect when - and we can remember presence across connectivity changes) (TODO: Possibly we should store desired presence (the finer-grained string one) and status message, per account, too? They probably don't make sense globally, but they do make sense per account) (TODO: The Nokia UI also has a concept of whatever you need to do to make this account go online, try to make it happen. The API will need some sort of support for that - but that should be global or group-based convenience API, probably) Yes, I would also add this if you have to go online, do it with this presence/message. [...] Also worth considering: * server capabilities (save capabilities so we know which accounts are capable of doing what, even while offline, so UIs can present appropriate info) Yes, makes sense again. Transient attributes of an account - -- Only valid during one MC run; never stored; set by MC in response to the environment, rather than being user-settable. b: Able to connect Determined dynamically by requirements of the CM/protocol (some possibilities: whether we have network connectivity, whether we're logged-in to any VPNs, whether avahi-daemon is running...) and whether they're met. Also, always FALSE if the stored params are no longer enough to make the CM happy, or if we have some stored params that the CM no longer supports (CM-specific UI code can either perform a migration automatically, or require user input; the best a UI can do in the absence of CM-specific knowledge is to notify the user and disable the account until they've fixed it) I agree on all this, but I would also add a separate flag for the cases described in the latter paragraph: the UI needs to know that there is something with the account that has to be fixed. So, an able to connect flag to indicate whether the account can be connected now, and another flag that says that the account is wrong/incomplete/the CM is not installed/etc., which are all things fixable by the user. [...] Account Group = There seem to be two sorts of group floating around: * user-assigned groups (personal and work accounts) * automatic capability-based grouping (accounts that need a network connection, accounts that can run all the time like Salut, accounts that should only try to connect when explicitly requested like gnome-phone-manager) I think the term account group should only apply to the user-assigned groups. Magical groups that the user can't assign should be something separate; above, I suggest a way to deal with these. I suggest to call the tags rather than groups (I mean the user-assigned ones). We might want to specify some well-known tags, such as work, home, toilet ;-), but still leave the possibility to different clients to group them with different criteria. For capability-based grouping we probably need some complex way of specifying the match rules. One possibility would have a list (most of the times consisting of a single element) of dictionaries listing
Re: [Telepathy] Account and AccountManager objects
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 28 Jan 2008 at 16:23:53 +0200, Alberto Mardegan wrote:
ext Simon McVittie wrote:
u (Connection_Presence_Type): Desired status
The status MC is or should be trying to achieve *when this account
is able to connect*.
What are the possible values for this? Just online/offline?
I was thinking any value except Unset actually... the current Nokia UI
has an option for what status do you want when you go online?, after all,
and on an internet tablet that you're not necessarily paying much
attention to, it may make sense that when you go online, it's with
status Away or Busy by default.
May be set to Offline by the user, to disable accounts.
I guess you mean ...to disable accounts from connecting automatically.
Sort of - I was thinking that the way to make an account connect, if it
hadn't already connected automatically, would be to call SetDesiredStatus()
or equivalent.
b: Able to connect
[...]
I agree on all this, but I would also add a separate flag for the cases
described in the latter paragraph: the UI needs to know that there is
something with the account that has to be fixed. So, an able to
connect flag to indicate whether the account can be connected now, and
another flag that says that the account is wrong/incomplete/the CM is
not installed/etc., which are all things fixable by the user.
Instead of a boolean, this might make more sense as a list of unmet
requirements, where an empty list means is OK.
(Obviously, we could choose to optimize this list into a bitfield ... or not.
Whichever makes more sense.)
I suggest to call the tags rather than groups (I mean the
user-assigned ones). We might want to specify some well-known tags, such
as work, home, toilet ;-), but still leave the possibility to
different clients to group them with different criteria.
Ah, here's where it gets interesting...
If the terminology is tags, an account can obviously have multiple tags.
If the terminology is groups, it's unclear. We shouldn't call this
concept tags unless we're prepared to commit to supporting many of
them (which perhaps we should be... I could be persuaded.)
I'm assuming that these tags or groups will be arbitrary strings assigned by
the user - we could suggest work or home, but they're free to use
whatever.
for instance
the account [EMAIL PROTECTED] could have these requirements:
{ ip-route: True, ap-name: work AP }
Whoa, whoa. ip-route there is clearly a technical requirement (Gabble
*needs* IP), but ap-name looks more like a user preference (you don't *want*
this account to auto-connect unless you're at work). Contradicting your
next paragraph:
An account with no requirements would be able to connect anytime.
I wouldn't mix the requirements (IP connectivity, availability of a
phone line, bluetooth, VPN,...) with the user preferences about when to
connect, which seems to be more fit for a UI: if the user doesn't want
to connect the gnome-phone-manager he can either disable the bluetooth,
or set the preferred connection status of that account to offline.
(The issue with g-p-m is that (I assume) you can't tell whether the phone
is around or not without polling for it periodically, which kills your
battery life... although as you say, the user can just turn off
Bluetooth to disable it.)
On the other hand, assuming CMs declare their own technical requirements
somehow (either automatically, or just by MC knowing that e.g. the
protocol 'local-xmpp' never needs an Internet connection), we won't really
be able to address the I only use this when I have a VPN use case in
an automated way - only the user's third-party VPN GUI addon knows what
VPNs are available, and only the user knows which accounts are VPN-only.
Unless you're suggesting that the VPN GUI tells MC to add a
user-settable tag for each configured VPN, called something like connect
automatically when vpn.example.com is up?
Urgh, this is tricky...
Simon
-BEGIN PGP SIGNATURE-
iD8DBQFHngDXWSc8zVUw7HYRAmxpAJ4ltuzZiJNoxy8E+rgKKs2zECVz4wCfYR0b
LD5rn8hyEub46ZB8t0CpGkc=
=6aqV
-END PGP SIGNATURE-
___
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 Mon, 28 Jan 2008 at 16:23:53 +0200, Alberto Mardegan wrote: ext Simon McVittie wrote: (TODO: The Nokia UI also has a concept of whatever you need to do to make this account go online, try to make it happen. The API will need some sort of support for that - but that should be global or group-based convenience API, probably) Yes, I would also add this if you have to go online, do it with this presence/message. So whatever UI causes the activation is responsible for deciding what status to set? That sounds rather mysterious... it sounds like a job for MC really. On the other hand, I suppose the UI might ask the user? - |To call Bob, you need to connect to the account | |Google Talk ([EMAIL PROTECTED]).| | | |Set this status: [ (-) Busy |v] | |with message:[On the phone__] | | | | [ OK ] [ Cancel ] | - Thinking about this some more, here are ways an account can become connected, and possible things we could do: * We gain an Internet connection, or do some other action that can trigger an onlineness event. Accounts that are so configured try to go online. Requirements to support this: either MC guesses an appropriate status for all accounts (in ITOS2008 it's a global preference), or each account has a stored value for when you get online, do this. Reasonable implementation: for each account, either store a boolean put this online whenever possible, or a presence type (possibly Offline) set this status whenever possible (I was leaning towards the latter in previous mails) * The user asks to initiate a call/IM session/... with a stored contact. That account has to go online first. Requirements to support this: either MC guesses an appropriate status for the account, or it uses the stored status from the previous case Reasonable implementation: the UI sketch above seems OK, actually. The UI could always ask MC what status would *you* set?, or perhaps pass in Connection_Presence_Type_Unset to trigger an MC decision, if it doesn't want to ask the user. * The same as the last one, but we weren't previously connected to a network, and we activate the network connection for the purpose (this is mostly an Internet-tablet case). Reasonable implementation: either we somehow freeze automatic connection for a short time, or we reason well, while they're going online anyway... and do the same as any other gaining an Internet connection event * The user explicitly asks to put this account online (implicitly selecting a status) * The user explicitly asks to put a group that includes this account, or all accounts, online (should probably be exactly the same as the previous) For the VPN use-case, we could have something in the Advanced tab of account config, I suppose: || | This account requires | | [ VPN vpn.example.com|v] | - -- together with some way for VPN plugins, etc. to add extra requirements. Simon -BEGIN PGP SIGNATURE- iD8DBQFHnhhZWSc8zVUw7HYRAvwMAJ0bUut/MxD9WaK63LKtnj1ZXa72zwCaAhv1 NRD+pu9tpBJwaRAGLI7U52A= =pclj -END PGP SIGNATURE- ___ 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
Here are some more attempts to nail down concepts before we get into API
design.
Preset
==
Presets consist of:
* the connection manager to use
* the protocol
* an internal preset name, not for UI (either globally unique or unique
per (CM, protocol) pair), e.g. gtalk
* parameter defaults (overriding those given by the CM, and overridden
by those given by the account)
Also worth considering:
* capability info
- e.g. we know ahead of time that all GTalk accounts have the same server
features - we can use this to pre-seed the Account's capabilities
- CM protocol implementations have this too, though
* the displayed name of the preset (localizable somehow)
- can probably also be used as (part of?) the default displayed name
for new accounts
* some specified way to select a default icon from a theme:
e.g. for the gtalk preset (which uses gabble) for the jabber protocol, use
telepathy-jabber-gabble-gtalk falling back to telepathy-jabber-gabble
and telepathy-jabber?
(Should the CM be part of the calculation or not? If so, it should be
less important than the protocol - users care about XMPP vs MSN
rather than Gabble vs Haze)
Presets should perhaps be exposed as read-only D-Bus objects by MC.
Nokia MC on the Internet Tablets has some extra info, but some of that should
be provided out of band by the UIs (e.g. accounts-plugin-gabble
knows how to handle gtalk specially, but that's between it and the
accounts UI).
Account
===
Stored attributes of an account
- ---
An Account is uniquely identified in the API by an object path.
s: Displayed name
User-selected. Account creation UI is responsible for picking a default
value appropriate for the user's locale - something like
g_strdup_printf (_(Google Talk (%s)), my_jid) would be reasonable
u (Connection_Presence_Type): Desired status
The status MC is or should be trying to achieve *when this account
is able to connect*.
May be set to Offline by the user, to disable accounts.
If you call methods to set this, MC acts on it, but only if the account is
able to connect.
(Rationale: if we define this to be when able to connect, we don't
have to change it in response to network connectivity - MC can use some
other mechanism to know which accounts can connect when - and we can
remember presence across connectivity changes)
(TODO: Possibly we should store desired presence (the finer-grained
string one) and status message, per account, too? They probably don't
make sense globally, but they do make sense per account)
(TODO: The Nokia UI also has a concept of whatever you need to do to
make this account go online, try to make it happen. The API will need
some sort of support for that - but that should be global or
group-based convenience API, probably)
s (/connection manager name/ as defined by Tp spec text): CM
s (Protocol): Protocol
s? nullable o?: Preset
Must be nullable somehow, for what used to be called vanilla profiles
a{sv}: CM parameter overrides
(ays): Avatar
To be uploaded to services that don't have server-stored avatars
- how can we tell? For the moment we have to assume they don't
s: Nickname
To be set as an alias once per connect on services that don't have
server-stored aliases
- same comments as Avatar
- terminology change in preparation for splitting the petname set by me
and nickname set by them functionality of Aliasing into separate
PetNames and Nicknames interfaces, which is a change we should make in
the Telepathy spec - see http://www.xmpp.org/extensions/xep-0165.html
§2.2 'The Roster as a Petname System'
Also worth considering:
* server capabilities (save capabilities so we know which accounts are
capable of doing what, even while offline, so UIs can present appropriate
info)
Transient attributes of an account
- --
Only valid during one MC run; never stored; set by MC in response to the
environment, rather than being user-settable.
b: Able to connect
Determined dynamically by requirements of the CM/protocol (some
possibilities: whether we have network connectivity, whether we're
logged-in to any VPNs, whether avahi-daemon is running...) and whether
they're met.
Also, always FALSE if the stored params are no longer enough
to make the CM happy, or if we have some stored params that the CM
no longer supports (CM-specific UI code can either perform a migration
automatically, or require user input; the best a UI can do in the
absence of CM-specific knowledge is to notify the user and disable the
account until they've fixed it)
nullable o: Connection (either it has one or it doesn't)
u (Connection_Status): Connection status
Might not actually need this, it can probably be implicit from whether
there's a connection, what the presence type is, and whether MC ought
to be trying to connect?
u
Re: [Telepathy] Account and AccountManager objects
2008/1/25, Simon McVittie [EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Here are some more attempts to nail down concepts before we get into API
design.
Preset
==
Presets consist of:
* the connection manager to use
* the protocol
* an internal preset name, not for UI (either globally unique or unique
per (CM, protocol) pair), e.g. gtalk
I vote for per (CM, protocol) pair.
* parameter defaults (overriding those given by the CM, and overridden
by those given by the account)
Also worth considering:
* capability info
- e.g. we know ahead of time that all GTalk accounts have the same
server
features - we can use this to pre-seed the Account's capabilities
- CM protocol implementations have this too, though
* the displayed name of the preset (localizable somehow)
- can probably also be used as (part of?) the default displayed name
for new accounts
Also a localized description text?
* some specified way to select a default icon from a theme:
e.g. for the gtalk preset (which uses gabble) for the jabber protocol,
use
telepathy-jabber-gabble-gtalk falling back to telepathy-jabber-gabble
and telepathy-jabber?
(Should the CM be part of the calculation or not? If so, it should be
less important than the protocol - users care about XMPP vs MSN
rather than Gabble vs Haze)
I think it could just provide an icon name and if it's not available in the
icon theme it's up to the UI to make a choice based on CM/Protocol.
Presets should perhaps be exposed as read-only D-Bus objects by MC.
Nokia MC on the Internet Tablets has some extra info, but some of that
should
be provided out of band by the UIs (e.g. accounts-plugin-gabble
knows how to handle gtalk specially, but that's between it and the
accounts UI).
Account
===
Stored attributes of an account
- ---
An Account is uniquely identified in the API by an object path.
s: Displayed name
User-selected. Account creation UI is responsible for picking a default
value appropriate for the user's locale - something like
g_strdup_printf (_(Google Talk (%s)), my_jid) would be reasonable
u (Connection_Presence_Type): Desired status
The status MC is or should be trying to achieve *when this account
is able to connect*.
May be set to Offline by the user, to disable accounts.
If you call methods to set this, MC acts on it, but only if the account is
able to connect.
(Rationale: if we define this to be when able to connect, we don't
have to change it in response to network connectivity - MC can use some
other mechanism to know which accounts can connect when - and we can
remember presence across connectivity changes)
(TODO: Possibly we should store desired presence (the finer-grained
string one) and status message, per account, too? They probably don't
make sense globally, but they do make sense per account)
(TODO: The Nokia UI also has a concept of whatever you need to do to
make this account go online, try to make it happen. The API will need
some sort of support for that - but that should be global or
group-based convenience API, probably)
s (/connection manager name/ as defined by Tp spec text): CM
s (Protocol): Protocol
s? nullable o?: Preset
Must be nullable somehow, for what used to be called vanilla profiles
a{sv}: CM parameter overrides
(ays): Avatar
To be uploaded to services that don't have server-stored avatars
- how can we tell? For the moment we have to assume they don't
s: Nickname
To be set as an alias once per connect on services that don't have
server-stored aliases
- same comments as Avatar
- terminology change in preparation for splitting the petname set by
me
and nickname set by them functionality of Aliasing into separate
PetNames and Nicknames interfaces, which is a change we should make in
the Telepathy spec - see http://www.xmpp.org/extensions/xep-0165.html
§2.2 'The Roster as a Petname System'
Also worth considering:
* server capabilities (save capabilities so we know which accounts are
capable of doing what, even while offline, so UIs can present
appropriate
info)
Transient attributes of an account
- --
Only valid during one MC run; never stored; set by MC in response to the
environment, rather than being user-settable.
b: Able to connect
Determined dynamically by requirements of the CM/protocol (some
possibilities: whether we have network connectivity, whether we're
logged-in to any VPNs, whether avahi-daemon is running...) and whether
they're met.
Also, always FALSE if the stored params are no longer enough
to make the CM happy, or if we have some stored params that the CM
no longer supports (CM-specific UI code can either perform a migration
automatically, or require user input; the best a UI can do in the
absence of CM-specific
Re: [Telepathy] Account and AccountManager objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 23 Jan 2008 at 08:57:13 +0200, Alberto Mardegan wrote: ext Simon McVittie wrote: Just what is an account? - - an independent identity - if I connect to XMPP as [EMAIL PROTECTED]/N810 and [EMAIL PROTECTED]/Laptop, I think we ought to think of that as one account From a MC POV, they are two different accounts: if you want to have them both connected from the same machine, you'll need 2 MC accounts, whose resource parameter will be different. I'm not saying that they're not conceptually different accounts now, I'm saying that perhaps they shouldn't be... Including the resource in the definition of an Account *would* give us the invariant that you can have at most one Connection to a given Account, which is perhaps good for everyone's sanity. On the other hand, in XMPP it's not guaranteed that you'll get the resource you ask for - if you connect as [EMAIL PROTECTED]/N810 the server may (and if it's gtalk, will) rename you to [EMAIL PROTECTED]/N810__5530ec76 or something. So, we can't necessarily look at a connection and tell which Account it is. MC currently has the concept of normalized name. Am I right in saying this is what you get by inspecting the self-handle? At the moment this doesn't necessarily give you a string you can pass as 'account' (see Salut, which has no account parameter, and if it did, it'd take a value like smcv rather than [EMAIL PROTECTED]); neither does it necessarily give you something globally unique (see Idle, in which my normalized name is just smcv regardless of whether I'm logged in to OFTC or Freenode) or even something uniquely identifying a connection (if you're logged on to the same XMPP account with two different resources, inspecting the self-handle will produce the same result). This is very deliberate - in Gabble, we actively don't want to distinguish between resources for contact handles. If we later support resources, we want to add extra interfaces to support them, rather than giving someone's account more than one handle. Perhaps we need to tighten up the spec wording somewhere to give MC a guarantee it can use. The normalized value of the self-handle uniquely identifies the account would be nice, although it isn't currently true. It is rumored that the next version of MSNP will have a resource-like mechanism for multiple simultaneous logins. I'm not sure what the backwards compatibility will look like, but I doubt it'll be pretty! I agreee with all the rest you wrote. I'd like to emphasize that one important statement that I'd like to be always valid is that a MC account can have at most one Telepathy connection at a time, and that obviously one Tp connection can be bound at most to one account. Now, this is difficult if we want MC to be able to pick up on existing Connections, e.g. after a crash, and associate them with an Account (which we do - the current behaviour of closing all Connections is somewhat unreasonable, given that you might not be able to get a given Connection back easily or at all). Consider this. I have configured XMPP Accounts for [EMAIL PROTECTED]/N810 and [EMAIL PROTECTED]/Test. MC restarts from a crash, and sees an XMPP Connection for which the inspected self-handle is [EMAIL PROTECTED], and the unique connection name (which doesn't currently exist, but suppose we support it later) is [EMAIL PROTECTED]/N810__5530ec76. How does it know that this is meant to be the first of my Accounts? The distinction between connections and accounts My loose usage of account while writing this message (even though I'm trying to be precise) illustrates a problem with a 0-1 connections per account, 0-1 accounts per connection model. [EMAIL PROTECTED] just *is* an XMPP account (or entity if you believe the RFC...), however much we try to redefine the word so that [EMAIL PROTECTED]/N810 is. I'd instead say that conceptually, [EMAIL PROTECTED] is an account, and [EMAIL PROTECTED]/N810 is a (potential) connection. Now, it could be useful for the MC Accounts API to be in terms of PotentialConnections rather than in terms of accounts, but I think it'd be a misleading use of terminology to call a potential connection an Account. When we inspect our own or other people's handles, we also want to get an account name, not a connection name. This is what Gabble does at the moment, anyway, and I think it'd be stupid to change that. It's also what Idle would do if we switched to having normalized handles be like [EMAIL PROTECTED] (and the more I think about that, the more I think we should make that switch). So, I'd argue for a model like this (in an ASCII-art entity-relationship diagram where o means zero or, - means one and means one or more): CM | o ^
Re: [Telepathy] Account and AccountManager objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I begin to wonder whether we should have a section in the Telepathy spec with protocol-specific notes, like the recommended mapping between JIDs/etc. and handles. On Wed, 23 Jan 2008 at 14:09:46 +, Will Thompson wrote: On Tue, Jan 22, 2008 at 05:38:41PM +, Simon McVittie wrote: - Haze: it's anyone's guess what libpurple does for any given protocol. * MSN: the account parameter is your .net Passport (or whatever it's called this week) ID, so something that looks like an email address; normalized handles are the same, lowercased. Good. Same as Butterfly. * ¿¡Yahoo‽: the account parameter is your username (something like lignojmik); normalized handles are the same, lowercased. The Yahoo - MSN bridge doesn't work in either direction in libpurple as far as I know, so I don't know how such contacts look. We don't know how bridged contacts ought to look either... * XMPP: the account parameter is your jid, optionally qualified with a resource. (I just remembered this; it's now fd.o bug #14212) Normalized handles are the lowercased, resourceless JID. Good, same as Gabble if you fix #14212. * AIM: these days, screennames can either be alphanumeric string starting with an letter, ignoring spaces and case, or a valid email address, or numeric strings, which are ICQ accounts. The account parameter can be any of these; normalized handles are lowercased and have whitespace removed. (libpurple doesn't actually care whether you supply an AIM screen name or an ICQ UIN when creating an AIM account — it just magically treats it as an ICQ account in the latter case. This is probably a bug.) * ICQ: as above. (You can talk to ICQ people from an AIM account.) Sounds good. * Myspace: account parameter is the email address you sign up to myspace with. Normalized handles are either such email addresses, or the alphanumeric string nnnrgh of a profile URL like http://www.myspace.com/nnnrgh. There's normalization from one form to the other (I can't remember the direction), which doesn't always work (kind of like the protocol plugin in general, actually, but the developer has just reappeared so maybe it'll improve!). Urgh. If I remember correctly, every myspace account is uniquely ID'd by an email address, and some (but not all) myspace accounts have a short name too? I doubt we particularly care about 100% correct semantics though :-P Protocols I know about that people (who aren't me and aren't excessively bored) don't use through Haze: * local-xmpp: as Salut, except you have to supply an account parameter, which is a bug. Yeah... but you can make it optional at the Tp level, and if missing, use the same algorithm as Salut, right? :-) * IRC: account parameter is [EMAIL PROTECTED] (fd.o bug #14213). Normalized handles are lowercased nicknames; e.g. resiak. The inconsistency is undesirable, but no-one uses IRC through Haze. This should get synced with Idle, when we've worked out what Idle should be doing. Simon -BEGIN PGP SIGNATURE- iD8DBQFHl1sCWSc8zVUw7HYRAt1iAJ90ZIKfFHdexxwmKVyISNiWWW2ojgCg5k1v WfXsEL4PUPCQ/4f+H8W/h30= =dtLM -END PGP SIGNATURE- ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] Account and AccountManager objects
On Wed, Jan 23, 2008 at 03:19:30PM +, Simon McVittie wrote: I begin to wonder whether we should have a section in the Telepathy spec with protocol-specific notes, like the recommended mapping between JIDs/etc. and handles. It would be better than do it like [Gabble/Salut]. :-) But, are many more different implementations of the same protocol likely? On Wed, 23 Jan 2008 at 14:09:46 +, Will Thompson wrote: * Myspace: account parameter is the email address you sign up to myspace with. Normalized handles are either such email addresses, or the alphanumeric string nnnrgh of a profile URL like http://www.myspace.com/nnnrgh. There's normalization from one form to the other (I can't remember the direction), which doesn't always work (kind of like the protocol plugin in general, actually, but the developer has just reappeared so maybe it'll improve!). Urgh. If I remember correctly, every myspace account is uniquely ID'd by an email address, and some (but not all) myspace accounts have a short name too? I doubt we particularly care about 100% correct semantics though :-P That's right. And, I believe that normalizing one to the other if the contact isn't on your buddy list involves a network round trip, which libpurple's normalization hook doesn't support. But, I'm sure all of the Telepathy + MyspaceIM users out there don't mind too much. :-) * local-xmpp: as Salut, except you have to supply an account parameter, which is a bug. Yeah... but you can make it optional at the Tp level, and if missing, use the same algorithm as Salut, right? :-) Yes, I could. It's now #14214. It's not high on my TODO list. -- Will signature.asc Description: Digital signature ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Account and AccountManager objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think the first thing we need to think about for Mission Control is the concept of an account. This message is a bit of a brain-dump. Just what is an account? - - an independent identity - if I connect to XMPP as [EMAIL PROTECTED]/N810 and [EMAIL PROTECTED]/Laptop, I think we ought to think of that as one account - but if I connect to IRC as smcv on OFTC and smcv on Freenode, that's two accounts - accounts can have different aliases, avatars, presence, and even anonymity requirements - - a way to get at contacts - each of my accounts can have different contact lists - I want to only talk to each contact from the account(s) they're aware of - I might want to talk to a colleague via my and his work accounts (to discuss XMPP) or via my and his personal accounts (to suggest we go to the pub) - - something Mission Control can connect in response to environmental changes - e.g. internet tablets' auto-online - therefore we need to store the complete parameter set for each account - - not (currently) necessarily the same as a normalized ID (which is the thing you get when you inspect a contact handle) Instructive cases to think about: - - The canonical example is, as usual, Gabble. The 'account' parameter is conceptually an account (although you can be connected to the same account multiple times from one host, if you're insane - just set two different resources). The 'account' parameter is globally unique and is the same as the self-handle's normalized value - [EMAIL PROTECTED] - - telepathy-sofiasip: here the 'account' parameter is [EMAIL PROTECTED], but a normalized user ID is sip:[EMAIL PROTECTED] or tel:+441234678910. AIUI the self-handle normalizes to sip:[EMAIL PROTECTED] too. (Mikhail, Senko: would a sip: URI be accepted as 'account'?) - - Idle: the 'account' parameter is e.g. 'User', the 'server' parameter is e.g. irc.freenode.net, you need both for an account name. The self-handle normalizes to 'user'. (Hmm, perhaps we should be normalizing all handles to [EMAIL PROTECTED] instead, so handles have globally unique values... obviously, the alias would still be User, and just a nick would still be accepted as input to RequestHandles) - - gnome-phone-manager: the phone is online whether you want it to be or not, you can't do RequestConnection() on it, and the self-handle (hopefully) normalizes to +441234567890 or whatever. (Yes, this is a bit of a weird one) - - Salut: there is no 'account' parameter. The self-handle normalizes to something like [EMAIL PROTECTED], but if there's a name collision, it might normalize to something different every time. (Aside: Sjoerd, should we rename published-name to 'account'? It basically does the same as 'account' in every other CM - the only weird thing is that it's optional and in fact shouldn't be used, whereas 'account' is usually required) - - Haze: it's anyone's guess what libpurple does for any given protocol. The Yahoo!!!1!one prpl has a boolean flag for am I yahoo.jp or not - does anyone know whether yahoo.com and yahoo.jp operate distinct namespaces? - - Butterfly: has some sort of multi-protocol madness going on. I've suggested that they normalize handles to URIs, but that might be doomed to failure since there is in fact no URI scheme for Y!M and MSNP that works in the same way as xmpp: - they use ymsgr:sendim?username and e.g. msnim:[EMAIL PROTECTED] (the URIs as verbs anti-pattern, as opposed to having noun-like URIs like xmpp:[EMAIL PROTECTED] or sip:[EMAIL PROTECTED]). - - telepathy-snom: what does it do? Desirable API - - Get from a Connection to the associated account - ideally, any old connection, not just one that was opened by the AccountManager - what happens if there isn't an associated account - create one automatically and set it disabled? - there's also a concept of is it good enough?, e.g. an unencrypted connection to an account for which you 'require-encryption' - it's the same account, but at the same time it's not what you asked for - failing that, the next best thing is any connection that was opened by the AccountManager - preferably, with some way to recover from AccountManager crashes - remember which connections were which accounts so we can resync, without having to close them all and start again like NMC currently does - we may need some help from the connection manager here (another argument for collapsing MC into the Telepathy spec rather than having it as a separate layer) - - Get from an account to a Connection, optionally connecting with some default presence - - Set parameters with which to connect, etc. - - Change presence, alias, avatar, ... for a subset of accounts (groups) - work vs personal accounts are the largest use case - work: e.g. Available, David Bloggs PhD, some boring
Re: [Telepathy] Account and AccountManager objects
Hi, -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ext Simon McVittie Sent: Tuesday, January 22, 2008 7:39 PM To: telepathy@lists.freedesktop.org Subject: [Telepathy] Account and AccountManager objects -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think the first thing we need to think about for Mission Control is the concept of an account. This message is a bit of a brain-dump. Just what is an account? - - an independent identity - if I connect to XMPP as [EMAIL PROTECTED]/N810 and [EMAIL PROTECTED]/Laptop, I think we ought to think of that as one account - but if I connect to IRC as smcv on OFTC and smcv on Freenode, that's two accounts - accounts can have different aliases, avatars, presence, and even anonymity requirements - - a way to get at contacts - each of my accounts can have different contact lists - I want to only talk to each contact from the account(s) they're aware of - I might want to talk to a colleague via my and his work accounts (to discuss XMPP) or via my and his personal accounts (to suggest we go to the pub) - - something Mission Control can connect in response to environmental changes - e.g. internet tablets' auto-online - therefore we need to store the complete parameter set for each account - - not (currently) necessarily the same as a normalized ID (which is the thing you get when you inspect a contact handle) Instructive cases to think about: - - The canonical example is, as usual, Gabble. The 'account' parameter is conceptually an account (although you can be connected to the same account multiple times from one host, if you're insane - just set two different resources). The 'account' parameter is globally unique and is the same as the self-handle's normalized value - [EMAIL PROTECTED] - - telepathy-sofiasip: here the 'account' parameter is [EMAIL PROTECTED], but a normalized user ID is sip:[EMAIL PROTECTED] or tel:+441234678910. AIUI the self-handle normalizes to sip:[EMAIL PROTECTED] too. (Mikhail, Senko: would a sip: URI be accepted as 'account'?) Yes. Moreover, it's the preferred form, which will leave out any fuzzy heuristics. There's also a gorgeous idea to implement umbrella accounts, where one account in terms of UI would mean two or more connections managed by different CMs. The case in point is Gizmo XMPP/Sipphone SIP. Here, some form of a cascade connection manager would be necessary that presents a front end unifying disparate protocol connections and their handle namespaces. Best regards, Mikhail ___ Telepathy mailing list Telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
