GNOME Bugzilla – Bug 641211
Add arbitrary-field interface for applications to store trivial per-person data
Last modified: 2015-01-20 17:44:55 UTC
+++ This bug was initially created as a clone of Bug #638279 +++ Folks clients could benefit from the ability to store trivial per-person data. Eg, Evolution's per-contact "wants HTML email" field. This would make it easier for the data to be kept sync'd with Individuals and could mean the difference between needing maintaining their own "add-on" database or not. Any client that wants to store non-trivial data should use their own database instead of this interface. This also points out a potential risk about adding this interface in the first place. See bug #638279 for prior discussion.
Do we have a use case for this (i.e. a program for which this functionality would already be useful)? Is this really something to get done for folks 0.3.5?
Punting to 0.3.7.
Punting bugs that won't be fixed by Folks 0.6.0.
This should probably just be based upon exposing a raw vCard for a Persona/Individual. That would let us also expose arbitrary vCard attributes we received from sources but couldn't fit into our structured classes. See bug#663715 comment#1
Going to work on this, so taking this bug
After some investigation on the previous discussions, I think we could do a couple things: * Add ExtendedInfoDetails interface, but making clear this is for fields that are not in the vcard spec, to avoid the problem of one backend supporting a field via ExtendedInfo and then having to implement the new interface if that field is later on supported in its own interface. The API for this would be a simple key/value pair API, maybe supporting AbstractFieldDetails so that parameters can be included in the field's value if needed. Also, maybe there should be API for retrieving a human readable description of the key, like X-MOZILLA-HTML (from eds) would give "Wants HTML email". * (maybe) move BirthdayDetails to a PersonalDetails and add there anniversary, spouse, and merge role also? This would be to reduce the number of interfaces, if wanted Anything I have missed?
(In reply to comment #6) > * Add ExtendedInfoDetails interface, but making clear this is for fields that > are not in the vcard spec, to avoid the problem of one backend supporting a > field via ExtendedInfo and then having to implement the new interface if that > field is later on supported in its own interface. The API for this would be a > simple key/value pair API, maybe supporting AbstractFieldDetails so that > parameters can be included in the field's value if needed. Sounds good. > Also, maybe there should be API for retrieving a human readable description of > the key, like X-MOZILLA-HTML (from eds) would give "Wants HTML email". I’m not sure about this. If an application is displaying/modifying a particular key, I think it will need some inbuilt knowledge about the key’s meaning. Relying on folks to provide that just means we’d have to keep adding more complexity (e.g. some way of rendering the correct widget for displaying/editing the key; some way of knowing when to enable editing for it; etc.) > * (maybe) move BirthdayDetails to a PersonalDetails and add there anniversary, > spouse, and merge role also? This would be to reduce the number of interfaces, > if wanted Moving the existing API would be a pain. How about creating a new FamilyDetails, and putting anniversary and spouse there? Roles are to do with positions of responsibility at work, not the family, so wouldn’t fit in either.
(In reply to comment #6) > * (maybe) move BirthdayDetails to a PersonalDetails and add there anniversary, > spouse, and merge role also? This would be to reduce the number of interfaces, > if wanted Like Philip said, first and foremost, I want to bundle together any API changes for Folks 0.90.x, where we will stabilize before freezing for 1.0. But beyond that, do you have specific uses in mind for anniversary and spouse? I know they're defined vCard fields but they've always seemed very "tick the feature box" to me because I can't think of any compelling use cases that require those fields. The only anniversaries (not counting birthdays) anyone really cares about is their wedding anniversary and maybe those of close relatives. In that case, they probably have them memorized, added to their calendar, or otherwise don't need them in their contacts store. Relationships between people can be interesting but that's better left to specialized apps focused on, eg, geneology, or huge-network-scale applications like Facebook, where the relationships will be maintained by the people involved. I wouldn't want to spend any time manually adding relationships to the contacts in my address book. Again, the ones I care about I have memorized. If we have a true arbitrary-field interface, applications can still add their own "x-anniversaryapp-anniverary" field if they really want
(In reply to comment #8) > (In reply to comment #6) > > > * (maybe) move BirthdayDetails to a PersonalDetails and add there anniversary, > > spouse, and merge role also? This would be to reduce the number of interfaces, > > if wanted > > Like Philip said, first and foremost, I want to bundle together any API changes > for Folks 0.90.x, where we will stabilize before freezing for 1.0. > > But beyond that, do you have specific uses in mind for anniversary and spouse? > I know they're defined vCard fields but they've always seemed very "tick the > feature box" to me because I can't think of any compelling use cases that > require those fields. The only anniversaries (not counting birthdays) anyone > really cares about is their wedding anniversary and maybe those of close > relatives. In that case, they probably have them memorized, added to their > calendar, or otherwise don't need them in their contacts store. > > Relationships between people can be interesting but that's better left to > specialized apps focused on, eg, geneology, or huge-network-scale applications > like Facebook, where the relationships will be maintained by the people > involved. I wouldn't want to spend any time manually adding relationships to > the contacts in my address book. Again, the ones I care about I have memorized. > > If we have a true arbitrary-field interface, applications can still add their > own "x-anniversaryapp-anniverary" field if they really want yes, was just adding this to the "plan" as I read in the previous discussions the will to limit the number of interfaces. But tbh, anniversary and spouse are, IMO, quite useless fiels, just that they are in both VCARD and EDS, so I thought we could want to support them. But as you said, this can easily be added, if any app wants to, via the arbitrary-field interface. And about that, here's a branch for a 1st review: https://git.gnome.org/browse/folks/log/?h=wip/arbitrary-field-interface still not working for me. I am writing a test suite but can't make it work, so I guess I am missing something, so would appreciate a quick review to see if I have missed anything.
(In reply to comment #8) > But beyond that, do you have specific uses in mind for anniversary and spouse? > I know they're defined vCard fields but they've always seemed very "tick the > feature box" to me because I can't think of any compelling use cases that > require those fields. I personally find the anniversary field quite useful, since I can never memorise dates, but I still want Evo to automatically create a calendar event for everyone’s anniversary. Spouse is useless though. > Relationships between people can be interesting but that's better left to > specialized apps focused on, eg, geneology, or huge-network-scale applications > like Facebook Agreed. (In reply to comment #9) > And about that, here's a branch for a 1st review: > > https://git.gnome.org/browse/folks/log/?h=wip/arbitrary-field-interface What doesn’t work about it? I’ve had a quick browse through, but it would be a lot easier to review if you attached the patches here. Some quick comments: > + * @since 0.9.4 Please use “@since UNRELEASED” so the branches don’t need changing if this misses a minor release. We replace ‘UNRELEASED’ as part of the release process. There’s some messed up whitespace around the ExtendedFieldDetails constructor. Folks does not use tabs. There doesn’t seem to be any API (or documentation of API) for removing a named ExtendedFieldDetails in the ExtendedInfo interface. Similarly, there’s no way to tell whether a named ExtendedFieldDetails exists. get_extended_field() should be documented to return null in that case, and its return value should be nullable (‘ExtendedFieldDetails?’). > + if ("extended_info" in p.writeable_properties) That should be “extended-info” with a hyphen. The canonical way to refer to name GObject properties is to use hyphens, not underscores.
Just pushed the last changes to https://git.gnome.org/browse/folks/log/?h=wip/arbitrary-field-interface . It now works, just missing the test case, which I'll submit soon.
(In reply to comment #11) > just missing the test case, which I'll submit soon. When you do, please produce a git-formatted patch and attach it here for review. Thanks!
Created attachment 292895 [details] [review] Add ExtendedInfo interface and implementation in EDS backend Implement ExtendedInfo in Individual Add ExtendedInfo interface EDS test
(In reply to comment #13) > Created an attachment (id=292895) [details] [review] > Add ExtendedInfo interface and implementation in EDS backend > > Implement ExtendedInfo in Individual > > Add ExtendedInfo interface EDS test This is a slightly updated version of the patch incorporating a few internal changes. It still needs to be checked wrt the review comments above. I’ve updated the wip/arbitrary-field-details branch.
Created attachment 295000 [details] [review] core: Add an ExtendedInfo interface for storing arbitrary fields This adds a new interface which allows clients to store arbitrary fields in backends. No backends currently implement it, but that will change. See the documentation for reasoning about when it’s appropriate to use this interface. New API: • ExtendedInfo interface • ExtendedFieldDetails class • Individual now implements ExtendedInfo
Created attachment 295001 [details] [review] eds: Implement ExtendedInfo interface Store extended info fields as arbitrary vCard properties.
Comment on attachment 292895 [details] [review] Add ExtendedInfo interface and implementation in EDS backend Updated patches which address all the review issues, pass unit tests, and I think are ready to commit.
Looks fine to me.
Great, thanks, merged! Attachment 295000 [details] pushed as 31018a7 - core: Add an ExtendedInfo interface for storing arbitrary fields Attachment 295001 [details] pushed as 699bf9a - eds: Implement ExtendedInfo interface