Re: [widgets] localStorage vs preferences

On Mon, Jul 20, 2009 at 7:10 PM, Scott
Wilson<scott.bradley.wilson@gmail.com> wrote:
> On 20 Jul 2009, at 16:29, Marcos Caceres wrote:
>
>> On 7/20/09 4:32 PM, Scott Wilson wrote:
>>>
>>> -1
>>>
>>> No, we should keep widget.preferences.
>>> If a UA wants to, it can simply implement it using:
>>>
>>> widget.preferences = window.localStorage;
>>
>> "If the UA wants to" seems kinda bad... I think the spec should say
>> something concrete about this. Either they are the same, or they are not.
>>
>> We can't have on some platforms authors expecting values being
>> simultaneously saved to widget.preferences and window.localStorage, and on
>> others not.
>
> A Widget author should be able to trust the implementation of the Widgets
> API, regardless of the UA. For conformance, having the UA implement
> widget.preferences reliably seems better for Widget authors.

Yes, I agree. Your point of reliability makes it clear that separation
between the storage mechanisms needs to be clear (I'll at least add a
note to the spec to say that window.localStorage and widget.preference
are different).

> Whether they can expect window.localStorage to work is a separate issue, and
> depends on what the UA is; the Widget author shouldn't need to worry about
> this as they should be able to develop widgets to run in any compliant UA,
> which could eventually be all kinds of devices and services, including ones
> like ours where window.localStorage doesn't really make sense.

 Agree.

>>> If it doesn't, the UA can do its own implementation, which we do for
>>> example, as for our UA localStorage is not an appropriate
>>> implementation, as our users are more likely to interact with the same
>>> widget using multiple browsers on multiple machines.
>>
>> Ok, I guess this means that your implementation of widget.preferences is
>> synchronizing multiple clients through some kind of server-sent events or
>> polling.
>
> Yes.
>
>>
>> However, can't you have a some kind of "synchronizer" that listens for
>> Storage event and the sends those to the server to propagate to dependent
>> clients?
>
> Far, far less easily and reliably than the reverse case of re-routing
> localStorage to preferences (above).
>

Ok, I'll have to take your word for that.

>>> We can also
>>> implement widget.preferences. We can't reimplement the user's
>>> browser's WebStorage impl (if it has one).
>>
>> Ok, understood. That makes sense from a "Wookie" perspective.
>>
>>> For more detailed arguments for keeping preferences, just search back
>>> through the list ;-)
>>>
>>> (We've already argued this one loads of times, Marcos! Why has it come
>>> up again?)
>>
>> I guess it helps me understand the problem and articulate use cases...
>> need a "Wookie" reminder to keep me in check :)
>
> Any time :-D
>



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

Received on Monday, 20 July 2009 17:34:24 UTC