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

[Julien PUYDT <jpuydt free fr>]

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
to stress two very important requirements :
I) all changes *must* be backward-compatible, since we're discussing 2.x.
II) all changes should be made keeping in mind that we will want to
improve on them later without breaking backward-compatibility.

1) D.Ciabrini mentionned the PlayPause method call of the
net.ekiga.calls is useless without some way to know if a call is on-hold
or not. I proposed a way to fix it in (and began working on a patch) :
http://bugzilla.gnome.org/show_bug.cgi?id=333465

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 :-/


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

3d- What about searching ?

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