[aerogear-dev] Fallback Strat for DataManager

Matthias Wessendorf matzew at apache.org
Mon Oct 28 10:38:04 EDT 2013


On Mon, Oct 28, 2013 at 3:36 PM, Kris Borchers <kris at redhat.com> wrote:

>
> On Oct 28, 2013, at 9:33 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
>
>
>
>
> On Mon, Oct 28, 2013 at 3:29 PM, Lucas Holmquist <lholmqui at redhat.com>wrote:
>
>>
>> On Oct 28, 2013, at 10:27 AM, Matthias Wessendorf <matzew at apache.org>
>> wrote:
>>
>>
>>
>>
>> On Mon, Oct 28, 2013 at 2:10 PM, Lucas Holmquist <lholmqui at redhat.com>wrote:
>>
>>> Hello Everybody,
>>>
>>> Now that we have support for IndexedDB and WebSQL in our Javascript
>>> library,  i've started a fallback strategy for DataManager.
>>>
>>> There will need to be a bit of deprecation since the 2 new adapters are
>>> asynchronous and return a promise/callbacks and the other adapters are
>>> synchronous and return the actual data.
>>>
>>> We are thinking of adding an option,  "aysnc", the name is up for
>>> debate,  which would only be valid for the memory and session/local
>>> adapters and would default to false and things would return as normal( this
>>> would also be removed in the next release and everything would be "async"
>>> ),  but if true, then these adapters would return like the 2 new adapters,
>>> using callbacks/promises.
>>>
>>
>> could we make it async only ?
>>
>>
>> it would be once we get to 1.4.0(?) since we need to deprecate
>>
>
> that's fine w/ me!
>
>
> Side note: I think we had _similar_ discussion in the past, and
> unfortunately ... we removed the async API ([1] from iOS).
>
>
> So the weird part here is that the localStorage and sessionStorage
> adapters will not be async. Even though they will return a promise, that
> promise will already be resolved because I/O on those operations is sync
> and we can't change that.
>

right


> So basically, these changes will make the API act async even though for
> those mentioned adapters, they will still technically be sync.
>

yep,


>
>
> [1] https://issues.jboss.org/browse/AEROGEAR-918
>
>
>
>>
>>
>>
>>
>>>
>>>
>>> Now on to the Fallback Strategy:
>>>
>>> Here is a use case:
>>>
>>> I'm a user,  i create an IndexedDB store,  but the device/browser i'm
>>> using doesn't support it.  I think there are 2 options we can go down here
>>>
>>>
>>> 1. The user gets an error back about IndexedDB being not support,  just
>>> like regular. And they need to "opt-in" to the fallback stuff.  this would
>>> be an option on the "add" of the Store.  Maybe the actual Constructor?
>>> They would also be able to provide a list of adapters to try which would
>>> override our predefined list.
>>>
>>>
>>> 2. Fallback is assumed and there is no option,  it just happens, using
>>> our predefined list.
>>>
>>
>>
>> I think it would be nice if the fallback just happens; However, there
>> might be the case that folks have a certain preference in actually
>> specifying the option. Not sure.
>> As of now I think I'd support the #2
>>
>>
>>>
>>>
>>> There is still the question of if the fallback is used,  and a
>>> "Asynchronous" store falls back to a "Synchronous" one,  what should be
>>> returned.  I'm thinking what ever the return value of the "Async" one was.
>>>
>>> I don't see this as breaking API since the "sync" store was not meant to
>>> be created "directly"
>>>
>>> So if they create an IndexedDB store and it fallbacks to a memory
>>> adapter,  this store will use the "async" model
>>>
>>
>> +1 makes sense
>> See question above :-)
>>
>>
>>>
>>>
>>> Thoughts, comments, cat pictures,
>>>
>>> -Luke
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131028/b567cd75/attachment-0001.html 


More information about the aerogear-dev mailing list