<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 26, 2014 at 11:38 AM, Erik Jan de Wit <span dir="ltr"><<a href="mailto:edewit@redhat.com" target="_blank">edewit@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"><br><div><div class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><span>Now the Javascript can verify that the callback is a function because it’s no longer a string and the need for a separate successHandler is overrated as you will either get messages or your errorHandler gets invoked. </span></div>
</div></blockquote><div><br></div><div><br></div><div>I like the idea of passing in a function (instead of a string), for the notification handling.</div><div><br></div><div>However, the successHandler was meant to give feedback if registration w/ UPS was successful or not. Should we really remove that hook ? </div>
</div></div></div></blockquote><div><br></div></div><div>Well you still will get that feedback, errorHandler will be invoked when it wan’t successful</div></div></div></blockquote><div><br></div><div>:-) figured that out after I sent my first mail :)))</div>
<div><br></div><div> </div><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><div class=""><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><span><div>Till now all these changes can be made on the plugin, but we could take it even further. Two things that are still platform dependent the senderId and the variantID/secret. Now senderId is ‘known’ by UPS so why do we need to specify it here? We could make senderId part of the response when registering a device on UPS then the client doesn’t need to specify it and all configuration is in one place.</div>
</span></div></blockquote><div><br></div><div>It's optional on UPS, as only really Android clients need it. And I think originally Luke just added the 'senderID' to UPS for having something handy (copy/paste usage).</div>
<div><br></div><div>So, I am not sure on that one, as that means we now have to enforce Android Variants always get the senderID attribute. Could be done, yes, but I am not sure.</div><div> </div></div></div></div></blockquote>
<div><br></div></div><div>Hmm, right it’s optional then this maybe not the greatest idea </div><div class=""><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><span><div><br></div><div>That leaves variantID/secret and that is the boldest proposal. How about we make it possible to register for an application instead for a specific variant? Then based on the meta information (deviceType, operatingSystem and osVersion) we choose the right variant.</div>
</span></div></blockquote><div><br></div><div>-1</div><div><br></div><div>we should never 'deploy' the masterSecret and the applicationID on clients. If that information is stolen (easy on devices), you can start sending dirty assaults to ALL the devices for that application. Same w/ all the different providers like Parse, Stackmob etc: they all use a MasterKey/Password for the actual send. And they _highly_ recommend NOT applying that to the clients (it's easy to leak that information)</div>
<div><br></div></div></div></div></blockquote><div><br></div></div>Right didn’t think about that, this together with the objections that Sebastien has makes this a definite no go.<br><br></div><br></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><br clear="all"><div><br></div>-- <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>
</div></div>