- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 24 May 2010 13:10:32 -0700
- To: Kris Zyp <kris@sitepen.com>
- Cc: "public-webapps@w3.org" <public-webapps@w3.org>
On Fri, May 21, 2010 at 6:59 PM, Kris Zyp <kris@sitepen.com> wrote:
>> or to use something like
>>
>> put(record, {forbidOverwrite: true}); // don't overwrite
>> put(record, {onlyOverwrite: true}); // must overwrite/update
>> put(record, {}); or put(record); // can do either
>>
>> or some such.
>>
>> However ultimately I feel like this directive will be used often
>> enough that it makes sense to create explicit API for it. The
>> implementation overhead of separate functions is really not that
>> big, and I can't see any usage overhead?
>
> I am not too concerned about the implementation. But, as we been using
> this API in SSJS, we have been increasingly using a wrapper pattern,
> wrapping low-level stores with additional functionality that exposes
> the same API. Wrappers add functionality such as caching, data change
> notifications, extra validation, and so. The more methods that are
> exposed the more difficult it is wrap stores.
Couldn't you always simply call addOrModify (or whatever we'll end up
calling it)? Given that neither localStorage or WebSQLDatabase
supports 'forbid overwrite' inserts it seems like this should work?
> Don't assume that the API will only be consumed.
Definitely. The API is definitely intended to be consumable by
libraries. In fact, I suspect that will be the case more often than
not. I'm not really sure that I'm following how the proposed API is
library un-friendly?
/ Jonas
Received on Monday, 24 May 2010 20:11:35 UTC