[aerogear-dev] Fallback Strat for DataManager

Tue Oct 29 11:10:45 EDT 2013

On Mon, Oct 28, 2013 at 5:53 PM, Corinne Krych <corinnekrych at gmail.com>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 at redhat.com> wrote:
>
> >
> > On Oct 28, 2013, at 10:36 AM, 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. 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 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
> >
> > _______________________________________________
> > 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/20131029/c578b665/attachment-0001.html 