[Telepathy] Account and AccountManager objects

[Simon McVittie]

-----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 bob at example.com 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-----