Re: [GnomeMeeting-devel-list] Refactoring the addressbook code

[Julien PUYDT <jpuydt free fr>]

Jan Schampera a écrit :
> Assuming you always meant ``for'' backend and ``for'' frontend.
> Then this is an interface definition important for the backens. It
> means you don't have to care about data you give to the interface.

Hmmm... I'm not sure I understand.

> > > - the GMContact "state" member is used to determinate offline,
> > > online and away status
> > Ok. Does SIP/SIMPLE allow to attach a string to the status ? (Like
> > "I'm gone for dinner -- be back near 20".) This is backend.
>
> That would also need a redefinition of GMContact.

Yes, hence my question ;-)

> > > - gmroster_modify_entry() only scans the "state" member of the
> > >   contact (to update the presence)
> > What if I want to rename sip:500 ekiga net from the "500" I set at
> > first to the saner "Miroir de test" ? This is backend.
>
> I'm still not sure if GMContact.uid is Ekiga-wide uniq, or only
> addressbook-wide uniq.

That is a good question.

> > > - the *_show_in_multiple_groups() will control, if a contact that
> > >   belongs to more then one group is shown in its first group found
> > > or in all groups found (discussion?)
> > I'm not sure I understand this one ; but it seems frontend.
>
> struct GmContact_ {
>  [...]
>  char *categories; /* Categories the user belongs to, comma separated */
>  [...]
> };
>
> That means, (GMContact*) foo->categories can be "Friends" OR
> "Friends,Enemies" - what to do in the latter case?

It's worse ; I remember I mentioned it when I complained about the use 
of g_str_split in ekiga : there's no way to distinguish a contact in the 
single group "friends,enemies" and to two groups "friends" and "enemies".

> > In my little pet project, I have a group named "Unsorted" exactly for 
> > that. This is frontend.
> Pet project? :)

A little buggy jabber client in ocaml. When I'm pissed with ekiga, I 
turn to it. It pisses me even more even faster, and I'm ready to come 
back to ekiga :-)

> > I really want a strict backend-frontend separation.
> You got that. The interface functions are separated into "what's called
> by the (a) backend engine" and "what's called by a UI control engine".

Hmmm...

> The interface itself can't be separated in "backend" and "frontend", as
> a UI is always frontend. I that definition, the mechanism that finds
> out the status of a contact and reports that to the roster is (one of)
> the backend(s) for the roster (another is e.g. the contacts management
> engine).

Hmmm... I'm not sure I understand.

Snark