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

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

Best regards,
Zoltan

Received on Thursday, 14 February 2013 17:46:04 UTC