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

[Jan Schampera <jan schampera web de>]

On Tue, 30 May 2006 07:56:45 +0200
Julien PUYDT <jpuydt free fr> wrote:

> >> *) why is there no "GmContact" anymore ? Because it just can't
> >exist. > There's so little in common between all we can put in an
> >addressbook > that it's better for each to manage its own stuff. For
> >example we have > the SIP roster contacts which will come with
> >presence, as the XMPP > contacts. But the avahi contacts won't. The
> >XMPP contacts will have a > notion of being authorized, etc.
> > 
> > Then what's the "common base" of all contacts? There must be
> > something like that, if I want to operate a contact in a general
> > manner. Or it ends up in something like
> > ::Connect(getcontactsSIPaddress(foocontact)) - but there's still at
> > least "something" (foocontact). A struct with a defined head and the
> > rest union? (I know those details shouldn't be in the design-stage,
> > but take it as it is).
> 
> There's not. The "find contacts" window doesn't have access to the 
> contacts. If the DBUS component uses the call history api, it will 
> access the call history items. The roster view in the main window will
> 
> now it uses the roster, and hence can access the items (although I
> don't  think it's really needed).
> 
> >> *) How would drag'n drop work ?
> > 
> > Using the information common to all types of contacts.
> 
> Which is the empty set.

Mh. I think i need to rephrase. Say, you're in the roster view, and want
to edit a contact (with a possible roster-viewer-right-click-menu [TM]).
What is used to identify the contact and how is it processed? I miss a
stone in the puzzle inside my head. Do you want the contact API layered
or similar?

J.

-- 
Once you've got the perfect hammer, everything looks like a nail.