On Mon, Jul 15, 2013 at 9:12 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:



On Mon, Jul 15, 2013 at 9:03 PM, Lucas Holmquist <lholmqui@redhat.com> wrote:

On Jul 15, 2013, at 3:01 PM, Sebastien Blanc <scm.blanc@gmail.com> wrote:




On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui@redhat.com> wrote:
here's a scenario.

A user creates an "Application" then adds a new "iOS Variant" to it.

they decide they need to rename this Variant since they didn't name it very well.

There is currently no way of renaming/ updating the description of this variant without re-sending the Certificate/pass phrase.  this would be the same for Android and Simple Push,  just substitute google key and channels

Is this really a problem ? Since before an update I assume you do a GET which will contain the Certificate/pass phrase, and then just doing an update passing the whole object again ... I might be missing sometyhing obvious here. 

i have all the info,  was hoping to avoid having to resend the certificate/other stuff again.

Ok I see, with the current model that is not really possible (saying trivially) . We could extract all this info (cert/pass whatever) into a different  model/class and just having a 1-1 relation making the update on the variant more simple. But I would like to have Matzew feedback on this.

yeah, that would a nice encaplusation, but not really needed, I guess/think

What we really need is a check on updates, as mentioned in my earlier email: if on update something is NULL, do NOT replace/update it (regardless if the cert/key/etc is encapsulated in its own class, or not). 

 


Also,  once we have a variant created,  we have a variant ID,  we should be able to use that ID( plus type? ) to do updates instead of having to pass the applicaitonID and variantID( same would go for a delete i guess ).


Not really sure the best way to handle this.

Should a user be able to update a certificate/key/channel once it has been created.  How would this affect any installations it might have?

thoughts?

-Luke
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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