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

[Julien PUYDT <jpuydt free fr>]

Julien PUYDT a �it :

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

> Again, the question is : in which format should the information about
> contacts be ?! (same problem as for the history).

Let me explain the issue in more details here.

We already were bitten by this when the account informations changed : 
it was stored in a string with a format like:
enabled|default|id|name|protocol|host|domain|username|password|timeout|method
and had to be changed to:
enabled|default|id|name|protocol|host|domain|username|auth_username|password|timeout|method
which broke our configurations. Small issue since it happened in cvs and 
 we were all well aware about it.

But still, it shows encoding things in a string like this just doesn't 
fly when you later decide you need more information. If you want to have 
a full list of places where this is used, just search for the function 
g_strsplit... the only place where it is rightfully used is in 
gmconf-glib.c (a list is stored, hence no upgrading issue).

My current train of thought is that probably some sort of xml stanza 
should be used to describe things.

Example :
1) At first, ekiga 2.2 exports contacts as is:
<item id='X12E45F0I42'>
  <name>Test</name>
  <sip>sip:500 ekiga net</sip>
</item>
and friendly programs know how to read this and get the information they 
need.
2) Then, ekiga 2.6 decides to export more information :
<item id='X12E45F0I42'>
  <name>Test</name>
  <sip>sip:500 ekiga net</sip>
  <comment>A mirror contact to do basic troubleshooting</comment>
</item>
and friendly programs used to the old format still work, while those 
knowing the new one can use it !

Of course, parsing those is more complex and will mean more code ; but 
at least it would age better.

It's probably not a good idea to fix the use of g_strplit to access 
configuration data in the 2.x series, but at least we should use a 
better approch for the new code. Especially for the dbus component, 
since it involves other programs, on which we don't want to impose big 
changes.

Comments?

Snark