<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 9, 2015 at 5:34 PM, Summers Pittman <span dir="ltr">&lt;<a href="mailto:supittma@redhat.com" target="_blank">supittma@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 03/09/2015 12:15 PM, Erik Jan de Wit wrote:<br>
&gt;&gt; Because Facebook and Google are well known for not making arbitrary changes to public apis and configurations.<br>
&gt;&gt;<br>
&gt;&gt; More importantly as an Open Source project hitching our code to the configuration of a third party proprietary system is terrifyingly bad karma.  Push is an exception ONLY because there isn&#39;t an equvalent open solution which has the same reach to devices.<br>
&gt; It’s just some configuration, what point does oauth2 have when it doesn’t work with Facebook and Google.<br>
</span>/me looks at the shoot and share demo, and the gdrive demo.<br>
Looks like it does work with FB and Google.  Did you have a specific<br>
example in mind?<br>
<span class="">&gt; The whole point of our libs is to make it easy for developers to do these complex things adding this config makes it super easy.  I don’t see: ”Terrifyingly bad karma” a good reason not to do this.<br>
</span>Because it is hitching our open source project to the largess of<br>
proprietary service vendors.  If they change THEIR configuration and OUR<br>
libraries break WE look like the bad guys not them for starters.<br></blockquote><div><br></div><div>That happened with push (Google&#39;s documentation, not the APIs) in the past, and may happen again. We reacted pretty quick on that one, which is what matters. If we would not react, we would look bad.</div><div><br></div><div>Perhaps we can add a statement that the code executes against a 3rd party service, that we don&#39;t own. That can even happen with differen Keycloak versions. However, usually actual API changes from the big players are usually announced, and it&#39;s usually comes with a little bit of time to react.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Additionally the only direction this can go is toward scope creep. Once<br>
we have Facebook and Google nothing is stopping (rhetorically) from<br>
adding Facebook, Yahoo, VK, Microsoft, etc.  Now we are maintaining 5x<br>
as many configurations as we were before. </blockquote><div><br></div><div>I&#39;d not add more, out of the blue. But if there is demand (from which ever direction), it&#39;s time to react on that demand, but not before</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Who is going to monitor those<br>
APIs and make sure they don&#39;t break/get deprecated?  Do we cut a release<br>
because one auth provider changed their config?<br>
<br>
Of course we don&#39;t because that is the responsibility of the app<br>
developer to make sure their configuration for the services they consume<br>
is up to date.  It is not and should not be our responsibility.<br>
<br>
I freely admit it is nice and it is convenient but it does not belong in<br>
the project.<br></blockquote><div><br></div><div>Instead, we don&#39;t offer any concrete impls for Google or Facebook? Or use a complicated and generic API, which may work, or not? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="im HOEnZb"><br>
<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; aerogear-dev mailing list<br>
&gt; <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
&gt; <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
</span><span class="im HOEnZb">--<br>
Summers Pittman<br>
&gt;&gt;Phone:404 941 4698<br>
&gt;&gt;Java is my crack.<br>
<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">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></div>
</div></div>