Re: [Alarm API] data … yet another DB?

On Thursday, 14 February 2013 at 17:45, Kis, Zoltan wrote:

> On Thu, Feb 14, 2013 at 6:26 PM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
> > On Thursday, 14 February 2013 at 16:03, Kis, Zoltan wrote:
> > > > No. But it gives us a single point of focus for that on the platform to mitigate those issues (technically and legally and for user control).
> > >  
> > >  
> > >  
> > > Moving issues under one hat does not necessarily simplify the problem
> > > when privacy is the issue. Quite the contrary: when one has to
> > > implement guaranteed privacy boundaries for user data (e.g. FB), and
> > > when at the moment one cannot use a generic database with
> > > row/column/object level security and still providing general search
> > > (the DB structure would look different depending on who is looking at
> > > it and whose data it tries to access) , a single database does not
> > > solve the privacy problem. IMO it is easier (if not the only way
> > > today) to solve this problem by using separate database storages, and
> > > centralized access control, e.g. the common techniques grouped in a
> > > library used by the DB managers, or a single DB manager supporting
> > > multiple physical storages and integrated with the file system and
> > > physical access layer (e.g. in case of flash).
> >  
> >  
> >  
> > Right. Bottom line is: "it's complicated."
> >  
> > Do you agree that adding yet another data store to the platform increases this complexity? If so, do acknowledge trying to use the existing solutions should be exhausted before we try to add yet more complexity into the platform?
> >  
> > I ask because I don't feel we've exhausted trying to use localStorage or IDB as a possible solution here.
>  
> I keep thinking that the main issue is not _what_ should we use to
> store the data to, but _how_. Your suggestion inflicts removing the
> argument from the signature, and trust the issue to the developer -
> who, as you suggest, could use localStorage or IndexedDB, but you
> don't tell how would that solve all the same issues, apart from that
> it's not this API's problem any more. If that outcome is reasonable,
> we'd better say no suggestions at all, just remove the argument as
> Mounir suggested too.

Sure, we can just code something up and see if it works. If the data argument goes away, the there is no reason for this API to be so heavy any more. Then you can the ID can be returned sync even if the system saves the ID asynchronously in the background, so:

var alarm = new Alarm(date, {…timezoneStuff...});
var data = {data: "hi", moarData: 123};
localStorage["alarm" + alarm.id] = JSON.stringify(data);

Would be a cheap and nasty way of doing it. You could build a more sophisticated data store from there. I'm not going to try to make an IDB version, but anyone else is welcome to :)
  

> I just wanted to say that the API will then lack this (IMO useful)
> feature, and while it is possible to solve the use case, it will be
> much harder for the developers, which subtracts from the value of the
> API.

Compare the above to the DOMRequest event/callback spaghetti you needed to deal with before.   
> However, I can understand why implementations would not want taking
> the responsibility of implementing it correctly, so it's a compromise,
> and for FPWD, probably we can move on with the simpler API.
>  

I hope so too.

Received on Thursday, 14 February 2013 17:52:20 UTC