Re: Contacts updates

2010/6/8 Wojciech Masłowski <wmaslowski@opera.comn>

>
> Contact interface seems quite minimalistic and doesn't specify any
> extension mechanism. There are many useful contact properties which aren't
> included in the spec like birthday, website etc. I understand that the
> reason for that is mostly because different addressbook implementations have
> different property sets and we want to specify only minimal set which will
> be supported by all implementations. The problem is that the proposed
> property set is still extensive enough to be unsupported on some platforms.
> For example oldest SIM cards supported only name and and phone number or
> Windows Mobile(Pocket Outlook) supports only 3 email addresses(in dap
> contacts API there can be arbitrary number of emails). Contacts API doesn't
> specify what to do in those cases ie what to do if the field is not
> supported by the service provider. Should saving the contact fail of should
> it succeed silently ignoring unsupported properties. I think this should be
> specified and possibly a mechanism should be added to detect which fields
> are supported.
>

We have discussed the fact that if fields are not supported across all
implementations they quickly become redundant. On the one hand we have a
situation where some platforms don't support even the minimal set of
properties already included in the spec and in other situations we don't
have enough properties. If I'm not mistaken that makes it pretty difficult
to produce a reasonable normalized set.

You mention that perhaps a mechanism to detect fields in an implementation
could be a solution. In practice that would:

- double the coding required from web app developers (API + field checking
code now required).
- require that the result of any field detection method also mean that the
field is ACTUALLY available (rather than saying it is and finding out during
a save() that it is actually not available for the selected data store)
- require a web app to check for support for every field before usage.
- require a web app to drop user data in the case that a field is not
supported in a given store.
- require a web app to know, ahead of time, which store the user will be
saving their data to in order too provide the necessary field checks. E.g.
Perhaps choosing a suitable store may become a part of an implementation's
'save process notification' that the user may be required to complete.
- inevitably lead to a user losing data when importing to and exporting from
different stores.

I'd like to avoid any and all of these circumstances from occurring.

I briefly mentioned an implementation strategy that was intended to
normalize all of these issues in [1]: that an implementation is capable, and
should be responsible, for filling the gap between the properties supported
in it's available stores and a full contact set mandated from a conformant
Contacts API implementation. I included a couple of real-world examples that
I hoped illustrated this could be considered as a practical proposal.

How much of that proposal is included in the Contacts API spec, or actually
needs to be included in the spec, we shall see. I'm currently working on
creating a full Portable Contacts compliant set of contact properties that
will be included shortly. By saying that a conformant implementation must
support the full contact set provided, an implementation designer should be
capable of designing their implementation to work with multiple stores while
still being compliant to a full properties set at the API level.



>
> About find I'm wondering if 'multiple' and 'limit' options aren't
> redundant?  Isn't limit = 1 equivalent of multiple = false, or am I missing
> something? Apart from that there is no specification which contacts are
> selected when there are more search results then limit, but I see a work in
> progress section for it.
>


I see your point that limit=1 is equivalent to multiple=false but I do not
think this duplication in functionality needs to be an issue. We could make
the multiple attribute to be interger-based, therefore implicitly
representing the limit attribute in the multiple attribute. What do you
think?

Regarding more results selected than limit, I'd expect the limit parameter
to be enforced by the implementation in their contact picker (don't allow
more object selections than limit). That may be an issue for a UA with a
'pre-defined trust relationship' with a user where no user interaction is
implied. In that case currently the result will be limited to the limit
value and there is potential that matching results will not make the
resulting return if number of results is greater than the current limit
value. Any proposals to counter this? I would say that in cases where no
user interaction is provided, the 'upper cardinality limit' would likely be
very high and the pending 'Search Sorting' section should provide guidelines
to handle this case.


>
> I'm also surprised that search mechanism doesn't provide a way of filtering
> using only specified properties and always searches them all. Besides that
> it may be inefficient to search all fields when what we are really
> interested is name(most common use case in my opinion), I see use cases of
> wanting to search only for specific fields. For example site would search
> for contacts whose birthday is today and notify you about it(ok I know b-day
> is not in the spec right now, but still I think it is a valid use case for
> it). Another use case could be an application which searches only for
> categories ie. If I search for people in the "work" category I wouldn't want
> Allan Worker from outside of this category to be found as well. Or for the
> matter of fact searching for Michael Link would also return all the contacts
> which have linkedin in serviceId.
>

This is a new addition to the specification and is included to simplify the
search filtering and also to suit the implied user interaction of the API as
it currently stands. In previous versions of the spec, the filter parameter
was of type ContactProperties. From my work, while this allowed more
granular matching to individual fields, the filtering applied was difficult
and confusing to represent in any resulting interface displayed to the user
to allow them to select contact objects to share.

Instead I propose a series of search weights to be applied to different
fields much like a number of search algorithms (e.g. Lucene) weight search
results according to their relevance. The 'name' property would be more
weighted than e.g. 'serviceId' properties. So in your example (searching for
Michael Link), the Michael Link record would pop up top of the search list.
Any 'linkedin.com' matches on the serviceId would also be matched but, with
a lower weighting, they would appear as the last objects in the resulting
success callback.

The implication is that the user can select only the items to return.
Subsequently, the web app knows where and how the search filter mapped to
ContactProperties so if you search for a specific birthday and some results
are returned, the web app is capable of going through the resulting objects
and saying 'if the match occurs on the birthday property then use this
record, otherwise ignore this result'. Essentially, the search filter is
entirely what it says: an intial filter to aid the selection of the correct
records, whether that be by the user and/or the web app as a result of the
resulting success callback.

Thanks,

- Richard

[1] http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0039.html