[Telepathy] Account and AccountManager objects

[Alberto Mardegan]

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.

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

Ok.

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

You'll see, but I think we want; since it's dictionary-based, what we 
might want to change is just some query string, keeping the method intact.

[...]
> 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?

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

But then it would make more sense to have this property list the 
parameters from the presets (which are static), rather than those that 
are pre-set (which can be dynamic).

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

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

Ok.

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

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!". :-)

Maybe, if the glib-bindings of properties turn out to be unusable, we 
might introduce a Set, Get and a GetAll methods for them, and map them 
to the C bindings as if they were implemented using DBus properties (so 
that when we switch to the real DBus properties, the C API doesn't change).
Anyway, we'll see.

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

I will, but IIRC there is not much libtelepathy on the client side of 
libmissioncontrol. But I'll check better next week (and try to get rid 
of the dependency).

Ciao,
   Alberto

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