[Telepathy] Account and AccountManager objects

[Alberto Mardegan]

ext Simon McVittie wrote:
> 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.

OK!

>>> 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...

OK. 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 :-)

OK. We could make the PresetParameters get updated as dynamic parameters 
get updated, so a UI could actually fill the fields as they are being 
computed.
In this case, the PresetParameters would reflect at any moment the 
dynamic (= not stored into the account settings) parameters that would 
be passed to the CM: that is, if the account if offline we would not try 
to compute them (which might cause the initiation of the provisioning 
process, and asking a password to the user), but simply return what we 
know about them at them moment.
Maybe I missed the goal of this property, but it seems messy and useless 
to me; it might have more sense to have a separate ComputedParameters 
(or rename it better) properties that is a dictionary of the parameters 
known at the moment, that is, Account parameters + .presets parameters + 
any dynamic parameters.

But at the moment I suggest to drop this property altogether: it's not 
essential and we can come to add it later, when we have a better 
understanding of what its use should be.

> 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.

Ahi! True...

> 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.

Good idea. In this case, in the account's settings there will be a 
boolean property indicating whether the account is dynamic; this 
property won't be directly exposed into the D-Bus interface, but 
indirectly by the presence of this Account.Interface.Dynamic interface.
This property might also be set in the .presets, if it's common for this 
service to have accounts with dynamic parameters.

> 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 bob at example.com and here
> is my password" and auto-detect everything from SRV and in-band
> negotiation, at least in principle).

Could be, but I don't see many benefits in this approach; we are just 
moving the problem to each CM, while it could be treated more generally 
in MC.

>> 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.

Good to know!

About your proposed specs, I would say they are quite OK, if you remove 
the yet unclear PresetParameters.

Ciao,
   Alberto

-- 
http://www.mardy.it <-- Geek in un lingua international!