Re: [Ekiga-devel-list] On XCAP and resource-lists standards

[yannick <sevmek free fr>]

Le jeudi 23 octobre 2008 à 14:16 +0200, Julien Puydt a écrit :
> Hi,
> 
> I have still no news from anyone about the way other clients than 
> eyebeam store their resource-lists.

Hello,

This is quite a complicated matter and unfortunately i did not have much
spare time lately to jump in this topic efficiently.

Still, resource-lists and correct integration with servers/clients using
this technology is _critical_ for the futur of our client. We had some
team internal discussions about this topic in a very high level (think
"human readable") langage. Now you have your hands in the mechanics and
this is very technical.

Simply put, I do believe XCAP technology is one way to reach the social
level IM client or VoIP client is meant to be. The goal is not only to
get working communication (text, audio and video and...) between 2
peers, it is to have a tool to manage/organise/deal with groups of
people. From a desktop usability point of view, this seems to be one of
the keys issue on the current discussion with free software, see this
e.g. http://www.markshuttleworth.com/archives/223 and this subsequent:
http://live.gnome.org/Boston2008/GUIHackfest/WindowManagementAndMore
And it seems people thinking about this are just _ignorant_ about the
current IETF work on this issue...

The RFC is here:
http://tools.ietf.org/html/rfc4825

Thank you Snark to work on this :D

> 
> I still worked on the issue :
> - I fixed a big memory leak in the current XCAP code ;
> - I managed (five minutes ago after a very long fight) to get openXCAP 
> up and running on my box -- and ekiga displays the list I expected.
> 
> Now the question I have is the following :
> - should I try to push the existing resource-lists code, which does 
> recursive list+entry but not entry-ref&external yet (read-only, of course) ;
> - or should I just get a clue from what I saw from eyebeam, and realize 
> resource-lists aren't  (1) meant to be seriously compatible from client 
> to client  (2) seriously supported in their full RFC-glory with 
> recursive lists, entry-ref and external by other clients anyway?

I've started to read on the topic, but it will take time for me to
understand how this technology is meant to work. My preliminary and
mostly ignorant thought is: ekiga has to be "seriously compatible from
client to client". I do not know if we have to do it right-now or if we
can have something more hackish for a start...

Unfortunately, I have to urgently give some help on ekiga.net first... I
wanted to let you know this has big interest to me and i will step in
ASAP.

Best regards,
Yannick

> 
> In the second case, I'll just make ekiga do a xmlns:gm="..." trick and 
> store a single <list> with <entry> children, said children having 
> <gm:group> children for the categories (ie : I'll be able to re-use [by 
> copying unfortunately] the local-roster code).
> 
> What do you think?
> 
> Snark
> _______________________________________________
> Ekiga-devel-list mailing list
> Ekiga-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
> 
-- 
Me joindre en téléphonie IP / vidéoconférence ?
sip:yannick ekiga net
Logiciel de VoIP Ekiga : http://www.ekiga.org
http://wiki.ekiga.org/index.php/Which_programs_work_with_Ekiga_%3F