<div dir="ltr"><div>I'm all for using promises that actually make sense,</div><div>but have you considered consistency?</div><div><br></div><div>Are you suggesting some modules will return jQuery.Deferred while others will use ES6 promises?</div>
<div><br></div><div>I would vote for all or nothing. ;-)</div><div><br></div><div><br></div><div>What about allow a developer to override what promise will be returned?</div><div>We can pass all promises through singleton (that can be overwritten/plugged-in by the developer),</div>
<div>and that will decide what promise to return.</div><div><br></div><div>In 1.x it can return jQuery.Deferred by default (but can be rewritten to Promise).</div><div>In 2.x it can return Promise (as in ES6) by default (but can be rewritten to jQuery.Deferred).</div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 1, 2014 at 3:36 PM, Sebastien Blanc <span dir="ltr"><<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Tue, Apr 1, 2014 at 3:17 PM, Lucas Holmquist <span dir="ltr"><<a href="mailto:lholmqui@redhat.com" target="_blank">lholmqui@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>in the canary branch i started looking at removing jQuery from the UnifiedPush client code, since it only uses jQuery.Ajax. </div>
<div><br></div><div><a href="https://github.com/aerogear/aerogear-js/tree/canary" target="_blank">https://github.com/aerogear/aerogear-js/tree/canary</a></div></div></blockquote><div><br></div></div><div>That's really cool and I will probably use this in my experimental FirefoxOS support for the Cordova Push Plugin </div>
<div><div class="h5">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>i was thinking this would be a 2.0 thing, but for this particular module/adapter/whatevs, i think we can update it before that since we marked it "experimental"</div>
<div><br></div><div>in datamanager we have the IndexedDB and WebSQL adapters marked as experimental, so we could do those, but since the other 2 adapters are not, we should probably wait.</div><div><br></div><div>Just want to see what the team thought about that, before i started to go cray-cray</div>
<div><br></div><div><br></div><div>-Luke</div><div><div><div><br></div><br><div><div>On Mar 25, 2014, at 8:58 AM, Lucas Holmquist <<a href="mailto:lholmqui@redhat.com" target="_blank">lholmqui@redhat.com</a>> wrote:</div>
<br><blockquote type="cite"><div style="word-wrap:break-word"><br><div><div>On Mar 25, 2014, at 8:15 AM, Lukáš Fryč <<a href="mailto:lukas.fryc@gmail.com" target="_blank">lukas.fryc@gmail.com</a>> wrote:</div><br><blockquote type="cite">
<div dir="ltr"><div>Side note: getting integration with jQuery{ajax,promises} right was one of the pain points when integrating with AeroGear.js / Angular (uses q.js, and custom http service).<br></div><div><br></div></div>
</blockquote><div>i know they include their "own" version of jQuery</div><br><blockquote type="cite"><div dir="ltr"><div>
We must be sure whatever we choose is compatible with frameworks out there (at least it should not hard-nut to make it work). In terms of promises implementation. In the end people may even end up using 2-3 promise approaches in one project that makes code pretty disgusting.</div>
<div><br></div><div>So:</div><div><br></div><div>+1 getting rid of jQuery.ajax<br></div><div>+1 getting rid of jQuery promises (they are just wrong anyway ;-)</div><div><br></div><div><br></div><div>Btw in terms of polyfilling, I would suggest:</div>
<div><br></div><div>1) use whatever standard <b>is</b> as long as supported by majority of mainstream browsers</div><div><br></div><div>2) use whatever standard <b>will be </b>and compile polyfill into aerogear.js (as long as it's not too bloated; not necessary for bower users)</div>
</div></blockquote><blockquote type="cite"><div dir="ltr">
<div><br></div></div></blockquote><div>the polyfill i was thinking about is here <a href="https://github.com/jakearchibald/es6-promise" target="_blank">https://github.com/jakearchibald/es6-promise</a></div><div><br></div>
<div>it is just the spec and 2kb gzipped, which is nice</div><div><br></div><div>and i think this could be an external( compiled in ) dep of the library</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div>
Wdyt?</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 12:26 PM, Karel Piwko <span dir="ltr"><<a href="mailto:kpiwko@redhat.com" target="_blank">kpiwko@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Given number of supported browsers is quite low - <a href="http://caniuse.com/promises" target="_blank">http://caniuse.com/promises</a>, I<br>
believe that polyfill will be needed even with version 2.0.<br>
<br>
On Mon, 24 Mar 2014 12:01:38 -0400<br>
<div><div>Lucas Holmquist <<a href="mailto:lholmqui@redhat.com" target="_blank">lholmqui@redhat.com</a>> wrote:<br>
<br>
><br>
> On Mar 24, 2014, at 11:55 AM, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>> wrote:<br>
><br>
> ><br>
> ><br>
> ><br>
> > On Mon, Mar 24, 2014 at 4:26 PM, Matthias Wessendorf <<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>><br>
> > wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Mon, Mar 24, 2014 at 4:14 PM, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com" target="_blank">scm.blanc@gmail.com</a>><br>
> > wrote:<br>
> ><br>
> ><br>
> ><br>
> > On Mon, Mar 24, 2014 at 4:05 PM, Lucas Holmquist <<a href="mailto:lholmqui@redhat.com" target="_blank">lholmqui@redhat.com</a>><br>
> > wrote:<br>
> ><br>
> > On Mar 24, 2014, at 10:10 AM, tolis emmanouilidis <<a href="mailto:tolisemm@gmail.com" target="_blank">tolisemm@gmail.com</a>><br>
> > wrote:<br>
> ><br>
> >> 2014-03-24 15:39 GMT+02:00 Matthias Wessendorf <<a href="mailto:matzew@apache.org" target="_blank">matzew@apache.org</a>>:<br>
> >><br>
> >><br>
> >><br>
> >> On Mon, Mar 24, 2014 at 2:03 PM, Lucas Holmquist <<a href="mailto:lholmqui@redhat.com" target="_blank">lholmqui@redhat.com</a>><br>
> >> wrote:<br>
> >>> I agree that it would be nice to implement AGJS-70 (Investigate removing<br>
> >>> jQuery requirement). Meanwhile, there is an open source project on GitHub<br>
> >>> that claims to offer a custom builder for jQuery in order to include only<br>
> >>> the modules needed [1] [2]. I haven't tried it yet but maybe we could<br>
> >>> create a custom jQuery build which includes only the parts currently<br>
> >>> needed in AeroGear. This would mean a smaller size of the jQuery<br>
> >>> dependency.<br>
> >><br>
> >> The AG lib depends on a few parts of jQuery, the biggest being jQuery.Ajax<br>
> >> and the promise implementation.<br>
> >><br>
> >> i know we can make custom builds of jQuery pretty easily( building from<br>
> >> source ), but i don't really want to bundle it within our lib.<br>
> >><br>
> >> and i don't think with bower we can do this easily. although they did just<br>
> >> add a post install hook, so perhaps that could be something to look at.<br>
> >><br>
> >> Datamanager only uses the promise implementation of jQuery( and some<br>
> >> random thing for the filter method, which could probably be updated ).<br>
> >><br>
> >><br>
> >> Promises are starting to become available natively in browsers and jQuery<br>
> >> doesn't use the Promise/A+ spec, so it could be harder to fallback<br>
> >> without a shim of some kind<br>
> >><br>
> >> Good to know. Thanks for providing this info.<br>
> >><br>
> >><br>
> >> sounds reasonable to 'wait' on the promise side of things, and use that<br>
> >> bit in the datamanager<br>
> >><br>
> >> +1<br>
> ><br>
> > there are other promise implementations that we could use, that are to<br>
> > spec, such as Q and RSVP, here is the link to the HTML5 rocks article<br>
> > <a href="http://www.html5rocks.com/en/tutorials/es6/promises/" target="_blank">http://www.html5rocks.com/en/tutorials/es6/promises/</a><br>
> ><br>
> > These last days I have been playing with the library When provided by Cujo,<br>
> > it's maybe also worth looking <a href="https://github.com/cujojs/when" target="_blank">https://github.com/cujojs/when</a><br>
> ><br>
> > not sure I see value in using a different library as a temporary thing.<br>
> > Once the API is part of the browser platform, the need for [yet another js<br>
> > lib] goes away. I know but I'm more concerned about "Once the API is part<br>
> > of the browser platform" When will that happen and does it match with our<br>
> > roadmap ? Was also to offer a polyfill for older browser if we want to keep<br>
> > supporting them.<br>
> ><br>
> i will have to update the roadmap.<br>
><br>
> 2.0 would be a nice time to "fully" switch, but we can start experimenting<br>
> now and maybe for 1.5 can have some implemenation for data manager only.<br>
><br>
> Current Chrome has Promise's enable by default and it looks like FireFox<br>
> 29( next version ) will too. Safari and IE are in dev i believe<br>
><br>
> for fallback we can still make use of jQuery i think because of this method<br>
> here "Promise.cast", although the closest lib to the spec is RSVP( maybe<br>
> this could be the 2.0 fallback if we remove jQuery from the whole lib )<br>
><br>
><br>
><br>
> ><br>
> ><br>
> ><br>
> ><br>
> >><br>
> >><br>
> >><br>
> >> while i don't really want to reinvent the wheel in terms of Ajax, it<br>
> >> might be interesting to take a look.<br>
> >><br>
> >> Yeah, IMO worth to look there, for reducing dependencies<br>
> >><br>
> >> -M<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> I think in a previous ML thread about what 2.0 looked like, that<br>
> >> Pipeline would maybe just be a JSON only thing, with exception for<br>
> >> multipart<br>
> >><br>
> >><br>
> >><br>
> >> @Lucas Thanks for making things clear<br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >><br>
> >> _______________________________________________<br>
> >> aerogear-dev mailing list<br>
> >> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> Matthias Wessendorf<br>
> >><br>
> >> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> >> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> >> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
> >><br>
> >> _______________________________________________<br>
> >> aerogear-dev mailing list<br>
> >> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> >><br>
> >> _______________________________________________<br>
> >> aerogear-dev mailing list<br>
> >> <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Matthias Wessendorf<br>
> ><br>
> > blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
> > sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
> > twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
> ><br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > aerogear-dev mailing list<br>
> > <a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br></div>
_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote>
</div><br></div>_______________________________________________<br>aerogear-dev mailing list<br><a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br><a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a></blockquote>
</div><br></div></div></div><br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org" target="_blank">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br></blockquote></div><br></div>