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

On Thu, Feb 14, 2013 at 2:51 PM, Marcos Caceres <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.

> 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.

> 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).

Best regards,
Zoltan

Received on Thursday, 14 February 2013 16:03:55 UTC