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



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]