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

[Julien PUYDT <jpuydt free fr>]

Damien Ciabrini a �it :
> 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']

Well, I did ask for a more explicit example, and you didn't give it 
until now, so I could hardly compare with your proposition. :-)

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

Both our approaches are very simple to encode. The difference is in 
decoding :
1) XML parsers are very current, and available in a wide variety of 
languages (just for C, I can name GMarkup, libxml2 and expat), while I 
have no idea how to parse your hashtable short of writing a new parser 
by hand ;
2) there is a clear and definite convention how to encode strings for 
use in a XML stanza (GMarkup has g_markup_escape_text for use with 
g_str_printf, libxml2 has its own more complete system)... while we 
would have to define precisely how to cope with strings containing (for 
example) quotes in the hashtable case.

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

As I said, returning a hashtable or a XML stanza is very easy... the 
problem lies in getting them as a result and knowing what to do with it.

Snark