After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 653543 - link_personas() should have a parameter to specify the linking attribute
link_personas() should have a parameter to specify the linking attribute
Status: RESOLVED WONTFIX
Product: folks
Classification: Platform
Component: libfolks
git master
Other Linux
: Normal normal
: Unset
Assigned To: folks-maint
folks-maint
Depends on:
Blocks:
 
 
Reported: 2011-06-28 06:15 UTC by Raul Gutierrez Segales
Modified: 2011-07-05 17:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Raul Gutierrez Segales 2011-06-28 06:15:18 UTC
While implementing the LocalId and WebServiceAddresses interfaces for the e-d-s backend, I've noticed that when you try to link e-d-s contacts by (say) web-service-addresses, you'll implicitly have a link via local ids too. 

Is this side-effect something desirable? 

I think that link_personas() should have a link_by parameter that could be an enum defined (something) like this:

public enum Folks.LinkBy {
   FIELD_ANY,
   FIELD_ALL,
   FIELD_IM_ADDRESSES,
   FIELD_WEB_SERVICE_ADDRESSES,
   FIELD_LOCAL_IDS
}

and the default value (by omission) would be folks.LinkBy.FIELD_ALL (which is the current behaviour).

Even though in practice users might end up going with FIELD_ALL most of the times, at least for testing purpose its nice to be able to say what you want instead of having Folks creating as many links as it can. 

Thoughts?
Comment 1 Philip Withnall 2011-06-28 07:30:44 UTC
I don't see any advantages to this. It complicates the API for the same end result (that the two Individuals are persistently linked somehow to form a new Individual).
Comment 2 Travis Reitter 2011-07-05 17:10:32 UTC
(In reply to comment #1)
> I don't see any advantages to this. It complicates the API for the same end
> result (that the two Individuals are persistently linked somehow to form a new
> Individual).

Agreed. Closing.