[aerogear-dev] JS Future Roadmap

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[aerogear-dev] JS Future Roadmap

Luke Holmquist

I was having some thoughts on the future of AeroGear.js that i needed to share.

Experimental Branch

I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc…

I feel this is the only way to drive innovation

I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in.

I still however want the code in this branch to be complete, not just random crap

2.0

I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme.

The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point

I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size

1.X Branch

Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority

This branch would still have a jQuery requirement and would be for legacy stuff( IE9 )


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

Sebastien Blanc
This sounds good. 

For 2.0, you speak about having our own AeroGear.Ajax(), do we also plan to rethink the concept of our pipeline ? There are some good stuff I really like , i.e the conventions for naming the endpoint, the save dealing with POST/PUT.

But in the same time I see all the frameworks like Ember or Angular having their own solution and when integrating AeroGear I wonder which one to use or why using one rather than the other.

I know that with sync, nice integrations are to come between pipes/datastore , maybe thinking on how we could integrate almost "transparently"  with this "uber cool" frameworks would help people adopting it.


  


On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist <[hidden email]> wrote:

I was having some thoughts on the future of AeroGear.js that i needed to share.

Experimental Branch

I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc…

I feel this is the only way to drive innovation

I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in.

I still however want the code in this branch to be complete, not just random crap

2.0

I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme.

The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point

I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size

1.X Branch

Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority

This branch would still have a jQuery requirement and would be for legacy stuff( IE9 )


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

Luke Holmquist

On Jan 18, 2014, at 2:31 PM, Sebastien Blanc <[hidden email]> wrote:

This sounds good. 

For 2.0, you speak about having our own AeroGear.Ajax(),
Well AeroGear.Ajax would only be an internal thing which pipeline and anything else that needed to talk to a server, like simplePush would use.  

do we also plan to rethink the concept of our pipeline ? There are some good stuff I really like , i.e the conventions for naming the endpoint, the save dealing with POST/PUT.

But in the same time I see all the frameworks like Ember or Angular having their own solution and when integrating AeroGear I wonder which one to use or why using one rather than the other.

I know that with sync, nice integrations are to come between pipes/datastore , maybe thinking on how we could integrate almost "transparently"  with this "uber cool" frameworks would help people adopting it.


  


On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist <[hidden email]> wrote:

I was having some thoughts on the future of AeroGear.js that i needed to share.

Experimental Branch

I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc…

I feel this is the only way to drive innovation

I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in.

I still however want the code in this branch to be complete, not just random crap

2.0

I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme.

The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point

I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size

1.X Branch

Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority

This branch would still have a jQuery requirement and would be for legacy stuff( IE9 )


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

Bruno Oliveira
In reply to this post by Luke Holmquist
+1000

--  
abstractj

On January 18, 2014 at 1:31:53 PM, Lucas Holmquist ([hidden email]) wrote:

>  
> I was having some thoughts on the future of AeroGear.js that i  
> needed to share.
>  
> Experimental Branch
>  
> I think i want to create a branch that is very experimental, that  
> targets new and upcoming API's, like Object.Observe, and Promises,  
> etc…
>  
> I feel this is the only way to drive innovation
>  
> I was thinking this is sort of our "Canary" branch, and when things  
> start to become less pollyfilly, then we can start to move these  
> features in.
>  
> I still however want the code in this branch to be complete, not  
> just random crap
>  
> 2.0
>  
> I would like to see that in 2.0 we start to remove our jQuery requirement,  
> and focus more on Modern Browsers and have our 1.X branch be our  
> less than modern browser( IE9 ) supported branch. much like how  
> jQuery has a 1.X and 2.X branch, obviously the difference between  
> our branches won't be as extreme.
>  
> The major thing we use jQuery for atm is jQuery.ajax and Promises.  
> this is nice for cross broswer compatibility and for transpoting  
> other things other than json, which brings me to my next point  
>  
> I would also like in 2.0 to make our library( pipeline ) only speak  
> json. I think this will make it really simple to have our own AeroGear.Ajax()  
> method and be able to keep it small in size
>  
> 1.X Branch
>  
> Once we hit all our 1.X milestones( sync, offline ) then what is  
> the current master branch would become a 1.X branch, and we recieve  
> bug fixes, but no new features. If something in the future could  
> be back ported, then maybe, but it wouldn't be a priority
>  
> This branch would still have a jQuery requirement and would be  
> for legacy stuff( IE9 )_______________________________________________  
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev 


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

Matthias Wessendorf
In reply to this post by Luke Holmquist



On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist <[hidden email]> wrote:

I was having some thoughts on the future of AeroGear.js that i needed to share.

Experimental Branch

I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc…

I feel this is the only way to drive innovation

I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in.

I still however want the code in this branch to be complete, not just random crap


+1 - also liking the name :-)

 

2.0

I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme.

The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point

I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size



+1; like the idea; for our iOS 2.x bits I'd imagine we do similar: iOS7/8 only and using AFN 2.x 

 

1.X Branch

Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority

This branch would still have a jQuery requirement and would be for legacy stuff( IE9 )


makes perfectly sense!

Great ideas!

-Matthias

 

_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

Corinne Krych

On 20 Jan 2014, at 09:51, Matthias Wessendorf <[hidden email]> wrote:

>
>
>
> On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist <[hidden email]> wrote:
> I was having some thoughts on the future of AeroGear.js that i needed to share.
>
> Experimental Branch

early adoptor branch or really experiemental ?

>
> I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc…
>
> I feel this is the only way to drive innovation
>
> I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in.
>
> I still however want the code in this branch to be complete, not just random crap
>
>
> +1 - also liking the name :-)

got the history for the name hew:
http://readwrite.com/2010/08/02/google_releases_canary_build_of_chrome_for_the_ear#awesm=~ottCjppZ0Ra6HL

"The name of the build refers to the old practice of miners to bring a canary into a coal mine. If poisonous gasses were present, the canary would die before it would kill the miners, acting as an alarm system."

>
>  
> 2.0
>
> I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme.
>
> The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point
>
> I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size
>
>
>
> +1; like the idea; for our iOS 2.x bits I'd imagine we do similar: iOS7/8 only and using AFN 2.x
>
>  
> 1.X Branch
>
> Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority
>
> This branch would still have a jQuery requirement and would be for legacy stuff( IE9 )
>
>
> makes perfectly sense!
>
> Great ideas!
>
> -Matthias
>
>  
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

Matthias Wessendorf



On Mon, Jan 20, 2014 at 10:49 AM, Corinne Krych <[hidden email]> wrote:

On 20 Jan 2014, at 09:51, Matthias Wessendorf <[hidden email]> wrote:

>
>
>
> On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist <[hidden email]> wrote:
> I was having some thoughts on the future of AeroGear.js that i needed to share.
>
> Experimental Branch

early adoptor branch or really experiemental ?

>
> I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc…
>
> I feel this is the only way to drive innovation
>
> I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in.
>
> I still however want the code in this branch to be complete, not just random crap
>
>
> +1 - also liking the name :-)

got the history for the name hew:
http://readwrite.com/2010/08/02/google_releases_canary_build_of_chrome_for_the_ear#awesm=~ottCjppZ0Ra6HL

"The name of the build refers to the old practice of miners to bring a canary into a coal mine. If poisonous gasses were present, the canary would die before it would kill the miners, acting as an alarm system."

awesome :-) 
 

>
>
> 2.0
>
> I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme.
>
> The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point
>
> I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size
>
>
>
> +1; like the idea; for our iOS 2.x bits I'd imagine we do similar: iOS7/8 only and using AFN 2.x
>
>
> 1.X Branch
>
> Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority
>
> This branch would still have a jQuery requirement and would be for legacy stuff( IE9 )
>
>
> makes perfectly sense!
>
> Great ideas!
>
> -Matthias
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

Luke Holmquist
In reply to this post by Corinne Krych

On Jan 20, 2014, at 4:49 AM, Corinne Krych <[hidden email]> wrote:

>
> On 20 Jan 2014, at 09:51, Matthias Wessendorf <[hidden email]> wrote:
>
>>
>>
>>
>> On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist <[hidden email]> wrote:
>> I was having some thoughts on the future of AeroGear.js that i needed to share.
>>
>> Experimental Branch
>
> early adoptor branch or really experimental ?
I imagine that to use this branch,  you would might need to turn on features in your browser,  like enabling experimental javascript in chrome for example.


>
>>
>> I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc…
>>
>> I feel this is the only way to drive innovation
>>
>> I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in.
>>
>> I still however want the code in this branch to be complete, not just random crap
>>
>>
>> +1 - also liking the name :-)
>
> got the history for the name hew:
> http://readwrite.com/2010/08/02/google_releases_canary_build_of_chrome_for_the_ear#awesm=~ottCjppZ0Ra6HL
>
> "The name of the build refers to the old practice of miners to bring a canary into a coal mine. If poisonous gasses were present, the canary would die before it would kill the miners, acting as an alarm system."
>
>>
>>
>> 2.0
>>
>> I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme.
>>
>> The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point
>>
>> I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size
>>
>>
>>
>> +1; like the idea; for our iOS 2.x bits I'd imagine we do similar: iOS7/8 only and using AFN 2.x
>>
>>
>> 1.X Branch
>>
>> Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority
>>
>> This branch would still have a jQuery requirement and would be for legacy stuff( IE9 )
>>
>>
>> makes perfectly sense!
>>
>> Great ideas!
>>
>> -Matthias
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> [hidden email]
>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

Luke Holmquist
In reply to this post by Matthias Wessendorf

On Jan 20, 2014, at 3:51 AM, Matthias Wessendorf <[hidden email]> wrote:




On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist <[hidden email]> wrote:

I was having some thoughts on the future of AeroGear.js that i needed to share.

Experimental Branch

I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc…

I feel this is the only way to drive innovation

I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in.

I still however want the code in this branch to be complete, not just random crap


+1 - also liking the name :-)

 

2.0

I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme.

The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point

I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size



I'm also tempted to remove "jsonp" support since there are risks with this


+1; like the idea; for our iOS 2.x bits I'd imagine we do similar: iOS7/8 only and using AFN 2.x 

 

1.X Branch

Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority

This branch would still have a jQuery requirement and would be for legacy stuff( IE9 )


makes perfectly sense!

Great ideas!

-Matthias

 

_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
qmx
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

qmx
Administrator
On Mon, Jan 20, 2014 at 01:14:24PM -0500, Lucas Holmquist wrote:
> I'm also tempted to remove "jsonp" support since there are risks with this

+9001, nowadays the right answer is setup CORS properly, right?

--
qmx
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

Luke Holmquist

On Jan 20, 2014, at 1:53 PM, Douglas Campos <[hidden email]> wrote:

> On Mon, Jan 20, 2014 at 01:14:24PM -0500, Lucas Holmquist wrote:
>> I'm also tempted to remove "jsonp" support since there are risks with this
>
> +9001, nowadays the right answer is setup CORS properly, right?

thats my thinking

>
> --
> qmx
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] JS Future Roadmap

Matthias Wessendorf
In reply to this post by qmx



On Mon, Jan 20, 2014 at 7:53 PM, Douglas Campos <[hidden email]> wrote:
On Mon, Jan 20, 2014 at 01:14:24PM -0500, Lucas Holmquist wrote:
> I'm also tempted to remove "jsonp" support since there are risks with this

+9001, nowadays the right answer is setup CORS properly, right?

+1
 

--
qmx
_______________________________________________
aerogear-dev mailing list
[hidden email]
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev