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.

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.

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

Thoughts, comments, cat pictures, -Luke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Oct 28, 2013, at 10:27 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Mon, Oct 28, 2013 at 2:10 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;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

> > > 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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Oct 28, 2013, at 10:33 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Mon, Oct 28, 2013 at 3:29 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > > On Oct 28, 2013, at 10:27 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Mon, Oct 28, 2013 at 2:10 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;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). we have no choice since IndexedDB and WebSQL are async

[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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Oct 28, 2013, at 9:33 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Mon, Oct 28, 2013 at 3:29 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > > On Oct 28, 2013, at 10:27 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Mon, Oct 28, 2013 at 2:10 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;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.

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

[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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Oct 28, 2013, at 10:36 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Oct 28, 2013, at 9:33 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> >> On Mon, Oct 28, 2013 at 3:29 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >> >> On Oct 28, 2013, at 10:27 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> >>> On Mon, Oct 28, 2013 at 2:10 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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. So basically, these changes will make the API act async even though for those mentioned adapters, they will still technically be sync. Yes, i think i missed that part. >> >> [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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Oct 28, 2013 at 5:53 PM, Corinne Krych <corinnekrych(a)gmail.com&gt; wrote: I think Matthias point is interesting, bringing up AEROGEAR-918 JIRA. Shouldn't we align API changes to reflect the asynchronous option on Store for all client platforms? yeah, I agree!

++ Corinne On Oct 28, 2013, at 3:38 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > On Oct 28, 2013, at 10:36 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Oct 28, 2013, at 9:33 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> >>> On Mon, Oct 28, 2013 at 3:29 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: >>> >>> On Oct 28, 2013, at 10:27 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>>> >>>> >>>> >>>> On Mon, Oct 28, 2013 at 2:10 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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. So basically, these changes will make the API act async even though for those mentioned adapters, they will still technically be sync. > Yes, i think i missed that part. > > >>> >>> [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(a)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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Oct 28, 2013, at 10:27 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Mon, Oct 28, 2013 at 2:10 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 ? > > > > 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 > anymore thoughts/comments on which fallback strategy should be used?

> > > 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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Oct 29, 2013, at 4:04 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Oct 29, 2013, at 2:52 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > >> >> On Oct 28, 2013, at 10:27 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> >>> On Mon, Oct 28, 2013 at 2:10 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 ? >>> >>> >>> >>> 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 >>> >> >> anymore thoughts/comments on which fallback strategy should be used? > > I prefer #1 for flexibility but #2 for simplicity. Honestly there are pluses and minuses both ways. In the spirit of abstractj since either way is probably fine, I say follow your heart. ;) that was very helpful. :) i think for now, i'll go with #2 for simplicity and create a JIRA to revisit and add the flexibility >> >> >>> >>> >>> 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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev