Re: [GnomeMeeting-devel-list] [DBUS] net.ekiga.history

[Damien Ciabrini <Damien Ciabrini sophia inria fr>]

Hi Snark,

On Tue, 2006-03-21 at 17:43 +0100, Julien PUYDT wrote:
> Hi,
> 
> here is the interface I discussed last time :
> 
>    <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>
> 
> Here is the list of information that *can* be available about a call in
> the history (as far as I can tell -- the code uses magic values like I 
> like them ;-) ) :
> - date (stored as "yyyy/MM/dd hh:mm:ss": we can't do better)
> - name
> - url
> - duration (not sure how it is stored)
> - reason why the call ended
> - software
> 
> And this is how I think it should be encoded as a string to go through
> dbus (formatted for human eyes) :
> <item url='sip:tricky ekiga net'>
>    <date>2006/03/21 13:41:27</date>
>    <name>Helpful Tester</name>
>    <duration>3:14:15</duration>
>    <endreason>Local user cleared the call</endreason>
>    <software>Ekiga 3.14159</software>
> </item>
> 
> With the following remarks :
> - the url *MUST* be there (does anyone think we could one day have
> something in the calls history without any url attached to it?);
> - all the rest is optional ;
> - of course the endreason will be translated.
> 
> This scheme should both be not-to-difficult to use, and scale well
> enough if we want to add anything new to the history.
> 

I don't know how difficult it is to encode the result into XML, but I
fail to see the robustness of the XML approach compared to the hastable
approach I proposed some days ago. I mean, from the user standpoint, the
result encoded into a hashtable would be something like:

[date='2006/03/21 13:41:27', name='Helpful Tester', duration='3:14:15',
endreason=4, software='Ekiga 3.14159']

What would be the advantage of an XML-encoded result ? I you have to
evolve the interface, you either:
  1. add a new field into the XML result. This can be implemented by
adding a new key in the hashtable-approach
  2. replace some field with another in the XML result. This evolution
should be avoid with both XML or hashtable approach, as it would break
existing bindings to ekiga.

I certainly have missed some important point... Anyway, note that my
remark is relevant only if returning a hastable instead of a piece of
XML is less difficult to implement :)

> What do you think about it ?
> 
> Snark
> 
> PS: I submitted bug #335377 about the callshistory code using magic values.
> 
> _______________________________________________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- 
Damien Ciabrini