Re: Feedback on Contacts API, informed by some Firefox Contacts prototyping

Hi Mike,

thanks a lot for this, some notes below.

On Jun 1, 2010, at 18:49 , Mike Hanson wrote:
> It causes some complications because of the possibility of queries overlapping in time.  I would like to see a small amount of commentary about what implementors should do to address concurrency issues.  The creation of a PendingOp in these cases introduces the possibility of a rollback, complicating things further.

I'm unsure of the degree to which PendingOp introduces rollback-related issues here. It is used in three cases: find(), save(), and remove(). Presumably cancelling find() produces no rollback of any kind. And since save() and remove() are both on a singular Contact object, I would expect them to be atomic? Am I missing something?

>  Are implementors required to enforce serialization, so that, e.g. a find() won't pick up records that have been removed() but not yet committed?  Or is an eventually-consistent approach sufficient?  Is each tab required to be coherent, or is coherency across tabs required?

All very good questions. Since you're implementing this, do you have any preference? Would it be reasonable to model this close to IndexedDB[0] since it's solving a more generic version of the same problem (albeit perhaps not over the network, but I'm not sure that's important here)?

> Also, there are subtleties associated with pending operations that are still inflight when a browser window is closed, or a browser-termination event is initiated.  Are those PendingOps implicitly cancelled?  Or are we required to make a best-effort to see them complete?  We should get feedback from the runtime experts about whether the proposed API for PendingOp is going to work in those cases.

PendingOp is:

[NoInterfaceObject]
interface PendingOp {
    void cancel ();
};

I agree that the window disappearing case is worth investigating, I do however wonder if specifying it is required for interoperability (and how testable it may prove to be generally). I also worry that if we go down that path we may end up having to distinguish between a variety of browser lifecycle events (crash, application shutdown, window closed, navigated away, etc.). Again, implementor feedback is welcome, and if another spec has solved this we should pilfer it joyously.

> I predict that implementors will encounter some pain when bulk edits are needed, since the current scheme requires a single-object-at-a-time pattern; for example, deleting all contacts with a given serviceId could be very slow.  The only way around that would be to add more bulk operations to "Contacts" -- e.g. Contacts.delete( {filterExpression} ).  That may be premature at this point but I predict some implementation pain here.

I think that the question here is how often are bulk edits actually needed? For instance, the BONDI API had a method to delete all contacts but it didn't prove to be very popular. If a very large family moves to another house you might have to update a number of address fields in bulk but we're still not looking at that many people (if anything it's an argument for greater normalisation in contacts APIs, but I'm afraid that ship sailed a while ago :). Is there a use case for bulk I haven't thought of? It smells like premature optimisation to me.

> Nulling of unknown attributes
> 
> The underlying assumption here is that the schema is fully normative, yes?  I'm okay with that in general, though (as I note in the section below) I'd really rather start from an existing schema and make assertions about which fields are mandatory and which must be removed.

We've been all the way around the block a few times on this one already. The great thing with existing schemata is that there are so many to choose from. If you have a detailed proposal here, we're more than happy to listen.

> multiple option
> 
> The presence of "multiple" in the options suggests that a behavior should be defined in (7) to indicate which match wins in the non-multiple case.  First one wins?

Good catch. I'm guess that if there's a sort, it's the first, otherwise it's whatever the implementation wants.

> Caller provides list of fields
> 
> I am partial to an option that allows the web content to indicate which fields of the person record they want (which allows us to construct a UI where the user grants, or denies, access to individual fields).  The presumption is that web content would never receive more data than they asked for, and may receive less.  I may be mistaken but I thought this feature was in an earlier draft?

It might not be clear enough, but my understanding is that that's still the intent. We've talked of improving this by showing the steps in a mock UI. Of course, we don't want to constrain the UI, but I agree that that's a valuable option.

> RFC2119 and Section 4.2:
> 
> The use of MUST language to restrict the behavior of a website that acts as a client to Contacts is a nice thought but feels totally unenforceable.  RFC2119 is intended to protect protocol interoperability, not to make moral claims about the use of an API, and using it in this way muddies the water a bit.  The fact is, bad actors will attempt to abuse this API, and in some cases they will succeed; we should put our effort into countermeasures.

Yeah, we know. There's already an action to change that section to match text that we have, it just hasn't been done.

> I note that the schema presented in the draft does not include birthday, which was demanded by one of the use cases in a prior draft.  A standardized schema that has already been through community review would help avoid omissions like that.

Yup.

> My preference would be for Portable Contacts, which is imperfect but has some momentum at this point.  

Portable Contacts is a workable option, one thing that I'm unsure of is whether we can do without the fields grandfathered from OpenSocial (drinker, scaredOf, lookingFor, favouriteTwilightCharacter, etc.). There are also a few things I don't like much, e.g. that it's unclear whether country is "France" (useless) or "fr".

More importantly, the breadth of PC means that we need to decide what to do when the underlying store can't handle a field that the developer is trying to add (e.g. you're exposing the rather daft iPhone address book). It's nice to have a schema that people use, but if half the time when you code against it half your fields just get lost, you don't have much of a useful spec (hence the current minimalistic approach).

> * The draft defines "name" as a singular field, which is insufficient for most applications and is particularly difficult for some localizations.  A givenName and familyName is important, and cultural norms differ about to handle these two fields.  Many mobile applications also demand a phonetic name field to enable voice recognition hints.  A structured "name" field leads to the desire for a "displayName", which would be identical to the "name" currently present in the draft.  Parsing human names is a really painful problem and if we have structured data I'd really prefer to maintain it.

We had that in one of the initial drafts, I'm unsure as to where it went.

> * Is an extension mechanism formally off the table?  

We've mostly talked about vendor prefixes. Do you have a specific proposal?


[0] http://dev.w3.org/2006/webapi/IndexedDB/

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 2 June 2010 12:34:48 UTC