Re: [GnomeMeeting-devel-list] [TOO LONG] Improving the dbus component after 2.0

[Damien Ciabrini <Damien Ciabrini sophia inria fr>]

On Thu, 2006-03-16 at 16:54 +0100, Julien PUYDT wrote:
> Hi,
> 
> the 2.0 DBUS component already has three interfaces :
> - net.ekiga.accounts ;
> - net.ekiga.calls ;
> - net.ekiga.self.
> 
> There are a number of ways we can improve it for 2.2 ; but I would like
[...]

> 2) D.Ciabrini (again ;-) ) wanted some way to access the history ; that
> would be a new interface net.ekiga.history. After some discussion, we
> agreed that being able to ask for the n last items of history (and
> getting less if there are not enough) was both simple and sufficient.
> 
> This would give something like this :
> 
>    <interface name="net.ekiga.history">
>      <method name="GetReceivedCalls">
>        <arg type="u" name="at_most" direction="in"/>
>        <arg type="as" direction="out"/>
>      </method>
>      <method name="GetPlacedCalls">
>        <arg type="u" name="at_most" direction="in"/>
>        <arg type="as" direction="out"/>
>      </method>
>      <method name="GetMissedCalls">
>        <arg type="u" name="at_most" direction="in"/>
>        <arg type="as" direction="out"/>
>      </method>
>    </interface>
> 
> Notice that I still have to figure out exactly what would be returned in
> the strings, since as far as I know we can have the date+time, the
> remote user address, the end reason, the duration and the software.
> Perhaps not all of that data for all call types :-/
> 
This new interface looks good to me. As for the return type, maybe the
solution could be to return an array of hashtables, since this kind of
type can be expressed in dbus. it would give something like:

     <method name="GetMissedCalls">
         <arg type="u" name="at_most" direction="in"/>
         <arg type="a{is}" direction="out"/>
     </method>

The hashtable would map ints (the keys) to strings (the values). This
may be more complex to implement in C but it believe it would accomodate
people using scripting langages such as python (including me of
course :P)

> 
> 3) I would like some way to have access to the addressbooks through
> dbus, through a  net.ekiga.addressbooks interface. I'm not sure yet
> how to do it  properly, but still, here are some ideas.
> 
> 3a- It should be possible to get the list of addressbooks, which would
> give something like :
> 
>    <method name="GetAddressbooks">
>       <arg type="as" direction="out"/>
>    </method>
>    <method name="ResignalAddressbookInfo">
>       <arg type="s" name="token" direction="in"/>
>     </method>
> 
>    <signal name="AddressbookAdded">
>      <arg type="s" name="token"/>
>    </signal>
>    <signal name="AddressbookRemoved">
>      <arg type="s" name="token"/>
>    </signal>
>    <signal name="AddressbookName">
>      <arg type="s" name="token"/>
>      <arg type="s" name="name"/>
>    </signal>
>    <signal name="AddressbookIsLocal">
>      <arg type="s" name="token"/>
>      <arg type="b" name="is_local"/>
>    </signal>
> 
> 3b- Getting the list of contacts would be doing mostly the same as for
> the addressbooks, using tokens for the contacts :
> 
>    <method name="GetAddressbookContacts">
>      <arg type="s" name="token" direction="in"/>
>      <arg type="as" direction="out"/>
>     </method>
> 
>    <signal name="AddressbookContactAdded">
>      <arg type="s" name="addressbook_token"/>
>      <arg type="s" name="contact_token"/>
>    </signal>
>    <signal name="AddressbookContactRemoved">
>      <arg type="s" name="addressbook_token"/>
>      <arg type="s" name="contact_token"/>
>    </signal>
> 
> 3c- Accessing the contact information would be:
> 
>    <method name="ResignalAddressbookContactInformation">
>      <arg type="s" name="addressbook_token" direction="in"/>
>      <arg type="s" name="contact_token" direction="in"/>
>    </method>
>    <method name="AddressbookAddContact">
>      <arg type="s" name="token" direction="in"/>
>      <arg type="s" name="information" direction="in"/>
>    </method>
>    <method name="AddressbookEditContact">
>      <arg type="s" name="addressbook_token" direction="in"/>
>      <arg type="s" name="contact_token" direction="in"/>
>      <arg type="s" name="information" direction="in"/>
>    </method>
>    <method name="AddressbookRemoveContact">
>      <arg type="s" name="addressbook_token" direction="in"/>
>      <arg type="s" name="contact_token" direction="in"/>
>    </method>
> 
>    <signal name="AddressbookContactInformation">
>      <arg type="s" name="addressbook_token"/>
>      <arg type="s" name="contact_token"/>
>      <arg type="s" name="information"/>
>    </signal>
> 
> Again, the question is : in which format should the information about
> contacts be ?! (same problem as for the history).
> 
Same remark as above. Intefaces look good.

> 3d- What about searching ?
Maybe for the moment it is enough to return the tokens as you propose,
and let the user reconstruct a entire information by querying
information for each token. ?

> 
> As a final remark : I'm not sure it will be that easy to implement those 
> interface since the addressbook code in ekiga doesn't work that way (the 
> separation backend-frontend isn't clear enough) : perhaps some 
> refactoring will be needed.
> 
> Snark
> 
> PS: I'm also wondering about http://telepathy.freedesktop.org/spec.html
> 
> _______________________________________________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- 
D.Ciabrini