Re: [GnomeMeeting-devel-list] [DRAFT] Organization of the "find contact" task

[Julien PUYDT <jpuydt free fr>]

Damien Sandras a écrit :
> Le lundi 29 mai 2006 à 21:17 +0200, Julien PUYDT a écrit :
> > Damien Sandras a écrit :
> > > So a source can contain several address books: remote, local, avahi, ...
> > A source doesn't "contain" addressbooks ; it manages them.
> >
> > And I wouldn't make the separation like you think but more like :
> > - call history
> > - avahi
> > - evolution-data-server
> > - kde's stuff
> > - XMPP rosters
> > - SIP roster (maybe obtained by filtering another addressbook)
>
> I still maintain that this notion shouldn't be presented to the
> programmer or to the user.

I maintain that the current code, on addressbook creation, gives me a 
drop down list, and when I choose one item in it, shows me a form to 
fill. What I propose is the same.

The sources' names and tooltips are visible only on addressbook 
creation. The rest of the time, you only see addressbooks' names. See 
attached screenshot of test code.

> > > I would simplify this: a source is an address book, and several types of
> > > address books are available.
> > A source is a "type of addressbook", in my mind.
> >
> > > The programmer shouldn't have to deal with
> > > sources, he should only deal with address books. The type of address
> > > book is determined by the URL, the rest is transparent.
> > An url !? Definitely no. Each addressbook will have a type of its own 
> > (AvahiBook, EDSBook, CallHistoryBook...) all inheriting from the common 
> > very primitive GmBook.
> You are probably going too far in complexity. Complex code leads to
> complex problems, even more in C.

I don't see where the code is complex... have a look to the sample code 
I sent you!

> > > >  From the point of view of the "find contact" window, an addressbook is
> > > > mostly opaque :
> > > > - it has a name
> > > > - it can notify when the name changes
> > > > - it can notify when it is removed
> > > OK, so from the point of view of the programmer:
> > > - the user adds an address book, does it trigger a callback connected to
> > > a signal or not?
> > When a source creates an addressbook, it triggers a "book-added" signal. 
> > If you watch this signal, there are two cases :
> > - you only know you're getting a new addressbook, and can display it by 
> > its name, and ask the source for a specific view ;
> > - you know it's a CallHistoryBook, and hence can use the more complete 
> > api associated to it.
> I do not have to know it is a CallHistoryBook. If I have to know it is a
> CallHistoryBook, it means I will have to "special case" a lot of code in
> the current code, adding many "switch" statements or "if" statements.

Yes and no.

Yes, I want specific code to export the call history through DBUS, so I 
want it available.

No, you don't need the "find contact" window to know it's a 
CallHistoryBook. It knows it's a GmBook from a GmSource, and delegates 
its management to the source (which knows the details). Look at the 
sample code I pasted to show how the window can display any addressbook 
with a very specific view, without knowing about how it's done!

Let's see it again :

 view = gm_source_create_view (source, book);

  (void)gtk_notebook_append_page (GTK_NOTEBOOK (carnet->priv->notebook),
                                  view, NULL);

we only know that view is a GtkWidget*, source a GmSource* and book a 
GmBook*, but still we'll have a nice display!

> > That's mostly it. Except that AvahiBook would be a *type* inheriting 
> > from GmBook, while AvahiSource would be a source, inheriting from GmSource.
>
> Inheriting in C?

GObject. Of course, there is some boilerplate code, but it's worth it.

> > For the creation, he would see that in the drop-down list, but he would 
> > also have a nice tooltip explaining what each is.
> I don't think it is the correct approach, think to non-technical people.

I think it's like the current approach, look at what we have :-)

> > > Imagine the find window, we search for "Damien Sandras", it will return
> > > various items containing Damien Sandras:
> > > - from the calls history
> > > - on Ekiga.net
> > > - from Bonjour
> > Hmmm... it's not clear that would fly. I don't think searching can be 
> > done in a common way on all addressbooks.
>
> I think it should be a prerequisite. Searching has to be done
> transparently, without having to take care of where we are searching.
> Look at how KAddressbook or Evolution-Data-Server are doing things. You
> have several types of address books, but the API is the same for all of
> them.

Do they show presence ? Do they have to care if a contact has an 
authorize/revoke action ?

Tell me just one thing that you could put in GmContact and would work 
for all types of contacts.

> > Say we have a XMPPView which knows it displays a XMMPBook. Since it has 
> > access to all the api of such a book (and knows the actions possible for 
> > its contacts), it will be able to propose "authorize" or "unauthorize" 
> > depending on the state, and only allow "call" if the contact advertized 
> > a VoIP capability.
>
> I think it is not a good way to handle thing, it will lead to code :
> - complex to write
> - having many special cases to be handled here and there in various
> parts of the current code
>
> Such code would be bad. I'm really not convinced by this part of your
> approach.

It isn't ; I sent you some sample code.

Snark