Re: I18N-ISSUE-65: find() method case sensitivity [Contacts API]

Josh

I think I understand your views -- I think that the use cases that you 
are thinking of are rather different to mine.

In particular, I'm thinking of a (web based) email app that wants to 
make use of the address book on the platform. I might want to build a UI 
that had an entry field that looked like a combo-box (INPUT & DATALIST 
in HTML5), and when I typed into the field, the app would fetch (and 
update the DOM with) a set of matching contacts, updating on each key 
press. Then, when I had typed enough characters, I might be left with 
one entry or a small number -- which I could then select between with a 
mouse (or cursor-down).

 From your answers, I think that you are focused on different use cases.

In any case, I think that spelling out the search string syntax would be 
useful. Does "her" match "Catherine"? Does "Cat in hat" match "Catherine 
Thatcher"? I think that the implicit assumption is that, given a string 
of words separated by spaces, each of those words must be found in the 
matched entry (in any order, any case, any position). Some people would 
argue that "her" should not match "Catherine", but "cat" should match. 
Maybe the search string field should include some idea of the field to 
be searched. For example, if I receive a SIP call, I might want to 
lookup the contact entry that has a matching telephone number. In this 
case, either the matching rules are extremely complex, or I might just 
want to say that I do a tail match -- i.e. 9789368623 matches +19789368623.

I agree that these are all very complex problems.

I'm thinking of the Contacts API as the interface to the database that 
comprises the user's address book. I suspect that you (and probably the 
spec) are thinking of it as the interface to the user interface that 
frontends the user's address book. In that case, I'm much happier about 
the vagueness of the match rules.

Philip

On 7/5/2011 3:34 PM, Josh Soref wrote:
> Philip wrote:
>> I'm puzzled -- the contents of the filter field seems undefined
>> (syntactically), with the only example being 'Bob'.
>> There is a note that
>> indicates that this field is to be interpreted by the contact list
>> provider, but this seems sufficiently vague as to be useless.
>
>> It isn't clear that I (as a web application author) can find out which
>> implementation of a contact list provider is present.
> Would it be helpful for us to make it explicit that you *cannot* find out which contact list providers are present?
>
> I'd support adding a statement to that effect.
>
>> Without this information, I'm not going to be able to produce the
>> correct form of the search filter string.
> If there are 20 providers and you provide a search filter string, you are not going to be able to provide a filter string which works for all of them if you assume that you can specially craft it for one of them. Just provide a basic filter of the things you'd like to get.
>
> Again, I'd be glad to propose text to spell this out to consumers.
>
>> [Compare this with browser implementations where they identify
>> themselves carefully so that I can build/use (admittedly ugly) cross
>> browser libraries.
> No, we do not want people writing:
> If (IE) { do_ie_stuff() }
> Else if (Safari) { do_safari_stuff() }
> Else if (Firefox) { do_firefox_stuff() }
>
> That leads to all other user agents breaking because the code doesn't write to the unexpected case of some other provider/agent.
>
>> I realize that the goal of this work is to eliminate (in theory) the
>> requirement for cross browser libraries, but that is why it is
>> important to be clear on the syntax and semantics of external APIs]
> The requirements are:
> * the consumer can ask for things which match some filter
> * the provider can provide anything it likes, but is encouraged to provide things which match
>
> Note that if you search for "Joshua" and I don't have any cards for "Joshua", but my user wants to send a card for "Josh", then I, as a user agent will gladly send the card for "Josh", because that's in fact that card that my user wants to send, and clearly you want to accept it because you're supposed to be acting on behalf of my user too.
>
> Again, if you'd like us to spell out this example, I'll be glad to provide text to that effect.
>
>> In particular, would you expect "bob jones" as a filter to match "Bobby
>> J Jones" (split into individual fields as appropriate)?
> I think it's likely that it would, but we're not going to guarantee that it will.
>
>> How about "Jones's Greek Kabob House"?
> If there are no matches for Bobby Jones, and the user knows that Bobby Jones owns "Jones's Greek Kabob House" and in fact wants to give that card to your application, then yes, I think it's reasonable to accept that if the user picks that contact card, it will be given to you.
>
> But no, it isn't likely to be given to you automatically.
>
>> If you can't say, then I think that the specification has failed as
>> every web author will have to implement their own filtering
> If you ask for "*", you will probably get a pissed user and 10 contacts.
>
> My phone has 1000 contacts, and there's no way that I'm going to tolerate 100 requests for contacts or be able to select 100 consecutive runs of 10 contacts.
>
> Note that "10" is merely an arbitrary limit that isn't in any specification, a client could give you all 1000, but it's free to suggest to the user that on average they're being attacked by a phishing thief and should only give out some select handful of contacts which make sense.
>
> For other cases, it's definitely possible for a UA to be unable to provide all possible contacts due to resource constraints (100,000 employees would kill your average mobile device), note that such constraints are an implied part of any API and are not to my understanding generally documented.
>
>> -- and it isn't clear that a web application can retrieve the entire
>> contacts list anyway due to underlying provider constraints.
> Indeed, there is no guarantee that an application or the user agent can retrieve such a list. We can certainly add a note reminding consumers of this.
>
> If a user works for a company with 100,000 employees (Cisco seems to have 70k), then it's possible that a UA can't possibly get that full list, and it's in fact likely that the user will not ever want to give it to an application.
>
> OTOH, it's probably part of an LDAP service to which I have access, so if an application on behalf of the user (you) asks for "Phil", the user (you) might be willing to give it your own contact card.
>
>> Think about LDAP based address books (or are these out of
>> scope?)
> No, they're well within scope. The API allows for a filter, and it allows for the user to provide any contacts the user chooses, whether or not they match the filter. Whether any API implementers are nice enough to do this remains to be seen, but I'm hopeful.
>
> Ideally the effective result of a search will be best effort. So if you over-specify a name, since if there are no matches and the user sees what you're trying to search for, the user is likely to be able to make a correction until the result that you are seeking on behalf of the user is met and thus returned.
>
> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ
Blog: http://wwwin-blogs.cisco.com/pgladsto/

Cisco.com - http://www.cisco.com

This email may contain confidential and privileged material for the sole 
use of the intended recipient. Any review, use, distribution or 
disclosure by others is strictly prohibited. If you are not the intended 
recipient (or authorized to receive for the recipient), please contact 
the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

Received on Tuesday, 5 July 2011 21:21:27 UTC