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

On Thursday, 14 February 2013 at 16:03, Kis, Zoltan wrote:

> On Thu, Feb 14, 2013 at 2:51 PM, Marcos Caceres <w3c@marcosc.com (mailto:w3c@marcosc.com)> wrote:
>  
> First of all, thank you for checking the specs, commenting on sysapps
> API's and working on making these API's better.

Happy to try to help :)

On Wednesday, 13 February 2013 at 21:41, Kis, Zoltan wrote:
> > Creating a persistent/long-lived object in the platform is certainly not a common thing.
>  
>  
> On Web platforms perhaps not yet, but they want to move there: in
> native platforms it is quite common.

Who is "they" and do you have a pointer to show "they are moving there"? And the availability on native does not necessarily mean it's a good (or bad) thing. Again, it's important to tease out the use cases, and not be tempted to just mirror native platform features because they are "quite common".     
> > Sure, you can already do that with its id. You just put that into localStorage or IDB along with the associated data.
>  
>  
> Perhaps localStorage.
>  
> > > But it depends on how are you going to use the storage, which still
> > > needs to be specified.
> >  
> >  
> >  
> > Who is "you" in the above?
>  
> The one who specifies it, and the one who implements it.
>  
> > Obviously, you can't specify how the developer uses the data (just
> that they get/set it). If "you" is an implementer, then, yes, you need
> to specify that, along with all the potential security issues, privacy
> issues… while keeping in mind all the regulatory issues that could
> arise (look at the regulatory mess cookies have made). Even
> localStorage got a lot of bad press as a new, more evil, super cookie.
>  
> > > Does it
> > > prevent the misuses enumerated before?
> >  
> >  
> >  
> > 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.  

--  
Marcos Caceres
http://datadriven.com.au

Received on Thursday, 14 February 2013 16:26:52 UTC