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

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jul 15, 2013, at 3:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;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.

> 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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. I think the same goes for renaming the Application construct? Though it just contains an extra "description" field, so it may not be worth it…

Would like to hear Matthew ideas on this as well from an API design point of view. :) Hylke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Jul 15, 2013 at 9:03 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > > On Jul 15, 2013, at 3:01 PM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > > On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;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.

> >> 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;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 > yes - but should be easy to change :-) See here: https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... in the "update", we just need to onbly update/replace those things that are NOT null. Of course, perhaps we need to rethink the "update validation" too: https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... Yes that could work even if I must admit I'm not a big fan of updating

> > 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. > the "variantID" is not a PK, but it's unique - so a new finder is what you need. > > Should a user be able to update a certificate/key/channel once it has > been created. yes, they should be able to replace an outdated (or revoked) certificate, API etc. > How would this affect any installations it might have? > Not at all. so if (speaking Androind) ... a new "project" is used - there is a new SenderID - that's more impact, since the actual mobile app needs to be updated, but again that's not really a concern for the push server > > thoughts? > > -Luke > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jul 16, 2013 at 9:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: On Tue, Jul 16, 2013 at 8:36 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 yes - but should be easy to change :-) See here: https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... in the "update", we just need to onbly update/replace those things that are NOT null. Of course, perhaps we need to rethink the "update validation" too: https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... Yes that could work even if I must admit I'm not a big fan of updating based on a null check ... Imagine someone wants to delete the description by setting it to null , that won't be possible ;) well, yeah - that (the desc) is optional - I was more interested in the required fields: e.g. for iOS Variant: * cert/passphrase (or googlekey/networkURL on other variants) PushApp: * name

(Well not sure it is a valid use case but you see my point) and as you said we must then rethink user validation. Other option is to split the update into more smaller specific updates methods ... but not sure about this also. 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. the "variantID" is not a PK, but it's unique - so a new finder is what you need. Should a user be able to update a certificate/key/channel once it has been created. yes, they should be able to replace an outdated (or revoked) certificate, API etc. How would this affect any installations it might have? Not at all. so if (speaking Androind) ... a new "project" is used - there is a new SenderID - that's more impact, since the actual mobile app needs to be updated, but again that's not really a concern for the push server thoughts? -Luke _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jul 16, 2013 at 2:05 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Jul 16, 2013, at 3:05 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Tue, Jul 16, 2013 at 9:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: > > > > On Tue, Jul 16, 2013 at 8:36 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 > > yes - but should be easy to change :-) > > See here: > https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... > > in the "update", we just need to onbly update/replace those things that are NOT null. Of course, perhaps we need to rethink the "update validation" too: > https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... > > Yes that could work even if I must admit I'm not a big fan of updating based on a null check ... Imagine someone wants to delete the description by setting it to null , that won't be possible ;) > > well, yeah - that (the desc) is optional - I was more interested in the required fields: > e.g. for iOS Variant: > * cert/passphrase (or googlekey/networkURL on other variants) > PushApp: > * name I'm not sure how I feel about this partial update. I'm not a big fan of saying "It's a required field but leave it null if you don't want it to change." Feels wrong. not sure I am following, but the required fields should never be null

If we are to do partial updates like this though, I would say it should probably use http PATCH instead of PUT, right? > > > > > (Well not sure it is a valid use case but you see my point) and as you said we must then rethink user validation. > Other option is to split the update into more smaller specific updates methods ... but not sure about this also. > > > > > > > > > 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. > > the "variantID" is not a PK, but it's unique - so a new finder is what you need. > > > > Should a user be able to update a certificate/key/channel once it has been created. > > yes, they should be able to replace an outdated (or revoked) certificate, API etc. > > > How would this affect any installations it might have? > > Not at all. so if (speaking Androind) ... a new "project" is used - there is a new SenderID - that's more impact, since the actual mobile app needs to be updated, but again that's not really a concern for the push server > > > > thoughts? > > -Luke > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jul 16, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Jul 16, 2013, at 7:10 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Tue, Jul 16, 2013 at 2:05 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jul 16, 2013, at 3:05 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> >> On Tue, Jul 16, 2013 at 9:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >> >> >> >> On Tue, Jul 16, 2013 at 8:36 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >> >> >> On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 >> >> yes - but should be easy to change :-) >> >> See here: >> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >> >> in the "update", we just need to onbly update/replace those things that are NOT null. Of course, perhaps we need to rethink the "update validation" too: >> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >> >> Yes that could work even if I must admit I'm not a big fan of updating based on a null check ... Imagine someone wants to delete the description by setting it to null , that won't be possible ;) >> >> well, yeah - that (the desc) is optional - I was more interested in the required fields: >> e.g. for iOS Variant: >> * cert/passphrase (or googlekey/networkURL on other variants) >> PushApp: >> * name > > I'm not sure how I feel about this partial update. I'm not a big fan of saying "It's a required field but leave it null if you don't want it to change." Feels wrong. > > not sure I am following, but the required fields should never be null Now I'm not following. :-) Let's go through a scenario and see how each would work with your method. Imagine there are currently values in every field. What fields need values and what can be null when: I update a single required field? I update a single optional field? Well,when I update the FORM and hit ENTER (let's assume this is a PUT, just for now..), aren't the entire form values sent? So, any field that changed will be udpated, I think Now if you NULL out a required field, I'd imagine that is not allowed.

> > > > If we are to do partial updates like this though, I would say it should probably use http PATCH instead of PUT, right? > >> >> >> >> >> (Well not sure it is a valid use case but you see my point) and as you said we must then rethink user validation. >> Other option is to split the update into more smaller specific updates methods ... but not sure about this also. >> >> >> >> >> >> >> >> >> 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. >> >> the "variantID" is not a PK, but it's unique - so a new finder is what you need. >> >> >> >> Should a user be able to update a certificate/key/channel once it has been created. >> >> yes, they should be able to replace an outdated (or revoked) certificate, API etc. >> >> >> How would this affect any installations it might have? >> >> Not at all. so if (speaking Androind) ... a new "project" is used - there is a new SenderID - that's more impact, since the actual mobile app needs to be updated, but again that's not really a concern for the push server >> >> >> >> thoughts? >> >> -Luke >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jul 16, 2013 at 2:23 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Jul 16, 2013, at 7:20 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Tue, Jul 16, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jul 16, 2013, at 7:10 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> >> On Tue, Jul 16, 2013 at 2:05 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >> On Jul 16, 2013, at 3:05 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> >>> On Tue, Jul 16, 2013 at 9:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>> >>> >>> >>> On Tue, Jul 16, 2013 at 8:36 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>> >>> >>> On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 >>> >>> yes - but should be easy to change :-) >>> >>> See here: >>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>> >>> in the "update", we just need to onbly update/replace those things that are NOT null. Of course, perhaps we need to rethink the "update validation" too: >>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>> >>> Yes that could work even if I must admit I'm not a big fan of updating based on a null check ... Imagine someone wants to delete the description by setting it to null , that won't be possible ;) >>> >>> well, yeah - that (the desc) is optional - I was more interested in the required fields: >>> e.g. for iOS Variant: >>> * cert/passphrase (or googlekey/networkURL on other variants) >>> PushApp: >>> * name >> >> I'm not sure how I feel about this partial update. I'm not a big fan of saying "It's a required field but leave it null if you don't want it to change." Feels wrong. >> >> not sure I am following, but the required fields should never be null > > Now I'm not following. > > :-) > > Let's go through a scenario and see how each would work with your method. Imagine there are currently values in every field. What fields need values and what can be null when: > > I update a single required field? > I update a single optional field? > > Well,when I update the FORM and hit ENTER (let's assume this is a PUT, just for now..), aren't the entire form values sent? > > So, any field that changed will be udpated, I think > > Now if you NULL out a required field, I'd imagine that is not allowed. So I guess I'm confused as to why there was any discussion of NULL fields being ignored then. If the form is filled in for the user, if they empty a field it should either fail (required field) or empty the value (optional field). +1 NULL should never just be ignored, right? I think, the "confusion" comes in..... what happens if (iOS Variant), JUST the name is changed (note: the certificate FILE is required). I guess that would be just fine... if (on the JUST iOSVariant.name is changed), we do not bother with the certificate. We update the certificate ONLY if it is actually part of the "UPDATE request".

-M > > > > >> >> >> >> If we are to do partial updates like this though, I would say it should probably use http PATCH instead of PUT, right? >> >>> >>> >>> >>> >>> (Well not sure it is a valid use case but you see my point) and as you said we must then rethink user validation. >>> Other option is to split the update into more smaller specific updates methods ... but not sure about this also. >>> >>> >>> >>> >>> >>> >>> >>> >>> 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. >>> >>> the "variantID" is not a PK, but it's unique - so a new finder is what you need. >>> >>> >>> >>> Should a user be able to update a certificate/key/channel once it has been created. >>> >>> yes, they should be able to replace an outdated (or revoked) certificate, API etc. >>> >>> >>> How would this affect any installations it might have? >>> >>> Not at all. so if (speaking Androind) ... a new "project" is used - there is a new SenderID - that's more impact, since the actual mobile app needs to be updated, but again that's not really a concern for the push server >>> >>> >>> >>> thoughts? >>> >>> -Luke >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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 >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jul 16, 2013, at 7:30 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Tue, Jul 16, 2013 at 2:23 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jul 16, 2013, at 7:20 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> >> On Tue, Jul 16, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >> On Jul 16, 2013, at 7:10 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> >>> On Tue, Jul 16, 2013 at 2:05 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>> On Jul 16, 2013, at 3:05 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>>> >>>> >>>> >>>> On Tue, Jul 16, 2013 at 9:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>> >>>> >>>> >>>> On Tue, Jul 16, 2013 at 8:36 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>> >>>> >>>> >>>> On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 >>>> >>>> yes - but should be easy to change :-) >>>> >>>> See here: >>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>> >>>> in the "update", we just need to onbly update/replace those things that are NOT null. Of course, perhaps we need to rethink the "update validation" too: >>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>> >>>> Yes that could work even if I must admit I'm not a big fan of updating based on a null check ... Imagine someone wants to delete the description by setting it to null , that won't be possible ;) >>>> >>>> well, yeah - that (the desc) is optional - I was more interested in the required fields: >>>> e.g. for iOS Variant: >>>> * cert/passphrase (or googlekey/networkURL on other variants) >>>> PushApp: >>>> * name >>> >>> I'm not sure how I feel about this partial update. I'm not a big fan of saying "It's a required field but leave it null if you don't want it to change." Feels wrong. >>> >>> not sure I am following, but the required fields should never be null >> >> Now I'm not following. >> >> :-) >> >> Let's go through a scenario and see how each would work with your method. Imagine there are currently values in every field. What fields need values and what can be null when: >> >> I update a single required field? >> I update a single optional field? >> >> Well,when I update the FORM and hit ENTER (let's assume this is a PUT, just for now..), aren't the entire form values sent? >> >> So, any field that changed will be udpated, I think >> >> Now if you NULL out a required field, I'd imagine that is not allowed. > > So I guess I'm confused as to why there was any discussion of NULL fields being ignored then. If the form is filled in for the user, if they empty a field it should either fail (required field) or empty the value (optional field). > > +1 > > NULL should never just be ignored, right? > > I think, the "confusion" comes in..... what happens if (iOS Variant), JUST the name is changed (note: the certificate FILE is required). > > > I guess that would be just fine... if (on the JUST iOSVariant.name is changed), we do not bother with the certificate. > > We update the certificate ONLY if it is actually part of the "UPDATE request". I see. Yeah that's pretty standard. What I have done in my app building past when dealing with files (certificate) is to show the current file name in the UI and if the file field is left blank, ignore that in the update.

> > > -M > > > > > > >> >> >> >> >>> >>> >>> >>> If we are to do partial updates like this though, I would say it should probably use http PATCH instead of PUT, right? >>> >>>> >>>> >>>> >>>> >>>> (Well not sure it is a valid use case but you see my point) and as you said we must then rethink user validation. >>>> Other option is to split the update into more smaller specific updates methods ... but not sure about this also. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> the "variantID" is not a PK, but it's unique - so a new finder is what you need. >>>> >>>> >>>> >>>> Should a user be able to update a certificate/key/channel once it has been created. >>>> >>>> yes, they should be able to replace an outdated (or revoked) certificate, API etc. >>>> >>>> >>>> How would this affect any installations it might have? >>>> >>>> Not at all. so if (speaking Androind) ... a new "project" is used - there is a new SenderID - that's more impact, since the actual mobile app needs to be updated, but again that's not really a concern for the push server >>>> >>>> >>>> >>>> thoughts? >>>> >>>> -Luke >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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 >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jul 16, 2013 at 2:39 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: On Jul 16, 2013, at 8:35 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jul 16, 2013, at 7:30 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> >> On Tue, Jul 16, 2013 at 2:23 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >> On Jul 16, 2013, at 7:20 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> >>> On Tue, Jul 16, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>> On Jul 16, 2013, at 7:10 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>>> >>>> >>>> >>>> On Tue, Jul 16, 2013 at 2:05 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>> >>>> On Jul 16, 2013, at 3:05 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jul 16, 2013 at 9:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Jul 16, 2013 at 8:36 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>> >>>>> >>>>> >>>>> On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 >>>>> >>>>> yes - but should be easy to change :-) >>>>> >>>>> See here: >>>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>>> >>>>> in the "update", we just need to onbly update/replace those things that are NOT null. Of course, perhaps we need to rethink the "update validation" too: >>>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>>> >>>>> Yes that could work even if I must admit I'm not a big fan of updating based on a null check ... Imagine someone wants to delete the description by setting it to null , that won't be possible ;) >>>>> >>>>> well, yeah - that (the desc) is optional - I was more interested in the required fields: >>>>> e.g. for iOS Variant: >>>>> * cert/passphrase (or googlekey/networkURL on other variants) >>>>> PushApp: >>>>> * name >>>> >>>> I'm not sure how I feel about this partial update. I'm not a big fan of saying "It's a required field but leave it null if you don't want it to change." Feels wrong. >>>> >>>> not sure I am following, but the required fields should never be null >>> >>> Now I'm not following. >>> >>> :-) >>> >>> Let's go through a scenario and see how each would work with your method. Imagine there are currently values in every field. What fields need values and what can be null when: >>> >>> I update a single required field? >>> I update a single optional field? >>> >>> Well,when I update the FORM and hit ENTER (let's assume this is a PUT, just for now..), aren't the entire form values sent? >>> >>> So, any field that changed will be udpated, I think >>> >>> Now if you NULL out a required field, I'd imagine that is not allowed. >> >> So I guess I'm confused as to why there was any discussion of NULL fields being ignored then. If the form is filled in for the user, if they empty a field it should either fail (required field) or empty the value (optional field). >> >> +1 >> >> NULL should never just be ignored, right? >> >> I think, the "confusion" comes in..... what happens if (iOS Variant), JUST the name is changed (note: the certificate FILE is required). >> >> >> I guess that would be just fine... if (on the JUST iOSVariant.name is changed), we do not bother with the certificate. >> >> We update the certificate ONLY if it is actually part of the "UPDATE request". > > I see. Yeah that's pretty standard. What I have done in my app building past when dealing with files (certificate) is to show the current file name in the UI and if the file field is left blank, ignore that in the update. that seems to be a good way of doing it. we would still need to change the logic on the endpoint method to ignore the certificate if its not there, or use PATCH? I'd say PUT (but I am not Roy Fielding ;-))

the thing i'd be worried about when resending the cert bits, do not do it :-) Only send IF a user really did select a file with the [input type:file] field, no ?

would be that some bit might change in the transfer and F up everything else >> >> >> -M >> >> >> >> >> >> >>> >>> >>> >>> >>>> >>>> >>>> >>>> If we are to do partial updates like this though, I would say it should probably use http PATCH instead of PUT, right? >>>> >>>>> >>>>> >>>>> >>>>> >>>>> (Well not sure it is a valid use case but you see my point) and as you said we must then rethink user validation. >>>>> Other option is to split the update into more smaller specific updates methods ... but not sure about this also. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 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. >>>>> >>>>> the "variantID" is not a PK, but it's unique - so a new finder is what you need. >>>>> >>>>> >>>>> >>>>> Should a user be able to update a certificate/key/channel once it has been created. >>>>> >>>>> yes, they should be able to replace an outdated (or revoked) certificate, API etc. >>>>> >>>>> >>>>> How would this affect any installations it might have? >>>>> >>>>> Not at all. so if (speaking Androind) ... a new "project" is used - there is a new SenderID - that's more impact, since the actual mobile app needs to be updated, but again that's not really a concern for the push server >>>>> >>>>> >>>>> >>>>> thoughts? >>>>> >>>>> -Luke >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)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 >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)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 >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Tue, Jul 16, 2013 at 3:15 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: On Jul 16, 2013, at 7:42 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > > > On Tue, Jul 16, 2013 at 2:39 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > On Jul 16, 2013, at 8:35 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Jul 16, 2013, at 7:30 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >> >>> >>> >>> >>> On Tue, Jul 16, 2013 at 2:23 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>> On Jul 16, 2013, at 7:20 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>>> >>>> >>>> >>>> On Tue, Jul 16, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>> >>>> On Jul 16, 2013, at 7:10 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jul 16, 2013 at 2:05 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>>>> >>>>> On Jul 16, 2013, at 3:05 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 16, 2013 at 9:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 16, 2013 at 8:36 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt; 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 >>>>>> >>>>>> yes - but should be easy to change :-) >>>>>> >>>>>> See here: >>>>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>>>> >>>>>> in the "update", we just need to onbly update/replace those things that are NOT null. Of course, perhaps we need to rethink the "update validation" too: >>>>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>>>> >>>>>> Yes that could work even if I must admit I'm not a big fan of updating based on a null check ... Imagine someone wants to delete the description by setting it to null , that won't be possible ;) >>>>>> >>>>>> well, yeah - that (the desc) is optional - I was more interested in the required fields: >>>>>> e.g. for iOS Variant: >>>>>> * cert/passphrase (or googlekey/networkURL on other variants) >>>>>> PushApp: >>>>>> * name >>>>> >>>>> I'm not sure how I feel about this partial update. I'm not a big fan of saying "It's a required field but leave it null if you don't want it to change." Feels wrong. >>>>> >>>>> not sure I am following, but the required fields should never be null >>>> >>>> Now I'm not following. >>>> >>>> :-) >>>> >>>> Let's go through a scenario and see how each would work with your method. Imagine there are currently values in every field. What fields need values and what can be null when: >>>> >>>> I update a single required field? >>>> I update a single optional field? >>>> >>>> Well,when I update the FORM and hit ENTER (let's assume this is a PUT, just for now..), aren't the entire form values sent? >>>> >>>> So, any field that changed will be udpated, I think >>>> >>>> Now if you NULL out a required field, I'd imagine that is not allowed. >>> >>> So I guess I'm confused as to why there was any discussion of NULL fields being ignored then. If the form is filled in for the user, if they empty a field it should either fail (required field) or empty the value (optional field). >>> >>> +1 >>> >>> NULL should never just be ignored, right? >>> >>> I think, the "confusion" comes in..... what happens if (iOS Variant), JUST the name is changed (note: the certificate FILE is required). >>> >>> >>> I guess that would be just fine... if (on the JUST iOSVariant.name is changed), we do not bother with the certificate. >>> >>> We update the certificate ONLY if it is actually part of the "UPDATE request". >> >> I see. Yeah that's pretty standard. What I have done in my app building past when dealing with files (certificate) is to show the current file name in the UI and if the file field is left blank, ignore that in the update. > > that seems to be a good way of doing it. we would still need to change the logic on the endpoint method to ignore the certificate if its not there, or use PATCH? > > I'd say PUT (but I am not Roy Fielding ;-)) I would vote PATCH to be correct but would not cry if it's PUT I guess. yeah - good call. I guess PATCH does make sense [1]. [1] http://www.mnot.net/blog/2012/09/05/patch > > > > the thing i'd be worried about when resending the cert bits, > > do not do it :-) Only send IF a user really did select a file with the [input type:file] field, no ? +1 > > would be that some bit might change in the transfer and F up everything else > >>> >>> >>> -M >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> If we are to do partial updates like this though, I would say it should probably use http PATCH instead of PUT, right? >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> (Well not sure it is a valid use case but you see my point) and as you said we must then rethink user validation. >>>>>> Other option is to split the update into more smaller specific updates methods ... but not sure about this also. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 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. >>>>>> >>>>>> the "variantID" is not a PK, but it's unique - so a new finder is what you need. >>>>>> >>>>>> >>>>>> >>>>>> Should a user be able to update a certificate/key/channel once it has been created. >>>>>> >>>>>> yes, they should be able to replace an outdated (or revoked) certificate, API etc. >>>>>> >>>>>> >>>>>> How would this affect any installations it might have? >>>>>> >>>>>> Not at all. so if (speaking Androind) ... a new "project" is used - there is a new SenderID - that's more impact, since the actual mobile app needs to be updated, but again that's not really a concern for the push server >>>>>> >>>>>> >>>>>> >>>>>> thoughts? >>>>>> >>>>>> -Luke >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)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 >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)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 >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)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 >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

so i've been using aerogear.js pipes to send my updates to the server. Currently we have no way of doing a PATCH, at least i don't think we do

On Jul 16, 2013, at 9:40 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: ok i'll create some JIRA's On Jul 16, 2013, at 9:23 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: On Tue, Jul 16, 2013 at 3:15 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > > On Jul 16, 2013, at 7:42 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Tue, Jul 16, 2013 at 2:39 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > >> >> On Jul 16, 2013, at 8:35 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >> >> On Jul 16, 2013, at 7:30 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> >> On Tue, Jul 16, 2013 at 2:23 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >> >>> >>> On Jul 16, 2013, at 7:20 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> >>> >>> >>> On Tue, Jul 16, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> >>>> On Jul 16, 2013, at 7:10 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> wrote: >>>> >>>> >>>> >>>> >>>> On Tue, Jul 16, 2013 at 2:05 PM, Kris Borchers <kris(a)redhat.com&gt;wrote: >>>> >>>>> >>>>> On Jul 16, 2013, at 3:05 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jul 16, 2013 at 9:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com >>>>> > wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 16, 2013 at 8:36 AM, Matthias Wessendorf < >>>>>> matzew(a)apache.org&gt; wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist < >>>>>>> lholmqui(a)redhat.com&gt; 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 >>>>>>>> >>>>>>> >>>>>>> yes - but should be easy to change :-) >>>>>>> >>>>>>> See here: >>>>>>> >>>>>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>>>>> >>>>>>> in the "update", we just need to onbly update/replace those things >>>>>>> that are NOT null. Of course, perhaps we need to rethink the "update >>>>>>> validation" too: >>>>>>> >>>>>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>>>>> >>>>>>> Yes that could work even if I must admit I'm not a big fan of >>>>>> updating based on a null check ... Imagine someone wants to delete the >>>>>> description by setting it to null , that won't be possible ;) >>>>>> >>>>> >>>>> well, yeah - that (the desc) is optional - I was more interested in >>>>> the required fields: >>>>> e.g. for iOS Variant: >>>>> * cert/passphrase (or googlekey/networkURL on other variants) >>>>> PushApp: >>>>> * name >>>>> >>>>> >>>>> I'm not sure how I feel about this partial update. I'm not a big fan >>>>> of saying "It's a required field but leave it null if you don't want it to >>>>> change." Feels wrong. >>>>> >>>> >>>> not sure I am following, but the required fields should never be null >>>> >>>> >>>> Now I'm not following. >>>> >>> >>> :-) >>> >>> >>>> Let's go through a scenario and see how each would work with your >>>> method. Imagine there are currently values in every field. What fields need >>>> values and what can be null when: >>>> >>>> I update a single required field? >>>> I update a single optional field? >>>> >>> >>> Well,when I update the FORM and hit ENTER (let's assume this is a PUT, >>> just for now..), aren't the entire form values sent? >>> >>> So, any field that changed will be udpated, I think >>> >>> Now if you NULL out a required field, I'd imagine that is not allowed. >>> >>> >>> So I guess I'm confused as to why there was any discussion of NULL >>> fields being ignored then. If the form is filled in for the user, if they >>> empty a field it should either fail (required field) or empty the value >>> (optional field). >>> >> >> +1 >> >> >>> NULL should never just be ignored, right? >>> >> >> I think, the "confusion" comes in..... what happens if (iOS Variant), >> JUST the name is changed (note: the certificate FILE is required). >> >> >> I guess that would be just fine... if (on the JUST iOSVariant.name is >> changed), we do not bother with the certificate. >> >> We update the certificate ONLY if it is actually part of the "UPDATE >> request". >> >> >> I see. Yeah that's pretty standard. What I have done in my app building >> past when dealing with files (certificate) is to show the current file name >> in the UI and if the file field is left blank, ignore that in the update. >> >> >> that seems to be a good way of doing it. we would still need to change >> the logic on the endpoint method to ignore the certificate if its not >> there, or use PATCH? >> > > I'd say PUT (but I am not Roy Fielding ;-)) > > > I would vote PATCH to be correct but would not cry if it's PUT I guess. > yeah - good call. I guess PATCH does make sense [1]. [1] http://www.mnot.net/blog/2012/09/05/patch > > > >> >> >> the thing i'd be worried about when resending the cert bits, >> > > do not do it :-) Only send IF a user really did select a file with the > [input type:file] field, no ? > > > +1 > > > >> would be that some bit might change in the transfer and F up everything >> else >> >> >> >> -M >> >> >> >> >> >> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> If we are to do partial updates like this though, I would say it >>>>> should probably use http PATCH instead of PUT, right? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> (Well not sure it is a valid use case but you see my point) and as >>>>>> you said we must then rethink user validation. >>>>>> Other option is to split the update into more smaller specific >>>>>> updates methods ... but not sure about this also. >>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>> >>>>>>> the "variantID" is not a PK, but it's unique - so a new finder is >>>>>>> what you need. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Should a user be able to update a certificate/key/channel once it >>>>>>>> has been created. >>>>>>> >>>>>>> >>>>>>> yes, they should be able to replace an outdated (or revoked) >>>>>>> certificate, API etc. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> How would this affect any installations it might have? >>>>>>>> >>>>>>> >>>>>>> Not at all. so if (speaking Androind) ... a new "project" is used >>>>>>> - there is a new SenderID - that's more impact, since the actual mobile app >>>>>>> needs to be updated, but again that's not really a concern for the push >>>>>>> server >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> thoughts? >>>>>>>> >>>>>>>> -Luke >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)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 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)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 >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)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 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)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 _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Jul 16, 2013, at 10:13 AM, Sebastien Blanc <scm.blanc(a)gmail.com&gt; wrote: On Tue, Jul 16, 2013 at 4:12 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > so i've been using aerogear.js pipes to send my updates to the server. > > Currently we have no way of doing a PATCH, at least i don't think we do > :) Good point Although until we get multipart support, i'll need to use regular jQuery ajax to upload the certificate anyway. so never mind. but maybe i'll create a JIRA about the PATCH support

> > On Jul 16, 2013, at 9:40 AM, Lucas Holmquist <lholmqui(a)redhat.com&gt; wrote: > > ok i'll create some JIRA's > > On Jul 16, 2013, at 9:23 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Tue, Jul 16, 2013 at 3:15 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: > >> >> On Jul 16, 2013, at 7:42 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> >> >> >> On Tue, Jul 16, 2013 at 2:39 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: >> >>> >>> On Jul 16, 2013, at 8:35 AM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>> >>> On Jul 16, 2013, at 7:30 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> >>> >>> >>> On Tue, Jul 16, 2013 at 2:23 PM, Kris Borchers <kris(a)redhat.com&gt; wrote: >>> >>>> >>>> On Jul 16, 2013, at 7:20 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>> wrote: >>>> >>>> >>>> >>>> >>>> On Tue, Jul 16, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com&gt;wrote: >>>> >>>>> >>>>> On Jul 16, 2013, at 7:10 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>>> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jul 16, 2013 at 2:05 PM, Kris Borchers <kris(a)redhat.com&gt;wrote: >>>>> >>>>>> >>>>>> On Jul 16, 2013, at 3:05 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jul 16, 2013 at 9:57 AM, Sebastien Blanc < >>>>>> scm.blanc(a)gmail.com&gt; wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jul 16, 2013 at 8:36 AM, Matthias Wessendorf < >>>>>>> matzew(a)apache.org&gt; wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist < >>>>>>>> lholmqui(a)redhat.com&gt; 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 >>>>>>>>> >>>>>>>> >>>>>>>> yes - but should be easy to change :-) >>>>>>>> >>>>>>>> See here: >>>>>>>> >>>>>>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>>>>>> >>>>>>>> in the "update", we just need to onbly update/replace those things >>>>>>>> that are NOT null. Of course, perhaps we need to rethink the "update >>>>>>>> validation" too: >>>>>>>> >>>>>>>> https://github.com/aerogear/aerogear-unified-push-server/blob/master/src/... >>>>>>>> >>>>>>>> Yes that could work even if I must admit I'm not a big fan of >>>>>>> updating based on a null check ... Imagine someone wants to delete the >>>>>>> description by setting it to null , that won't be possible ;) >>>>>>> >>>>>> >>>>>> well, yeah - that (the desc) is optional - I was more interested in >>>>>> the required fields: >>>>>> e.g. for iOS Variant: >>>>>> * cert/passphrase (or googlekey/networkURL on other variants) >>>>>> PushApp: >>>>>> * name >>>>>> >>>>>> >>>>>> I'm not sure how I feel about this partial update. I'm not a big fan >>>>>> of saying "It's a required field but leave it null if you don't want it to >>>>>> change." Feels wrong. >>>>>> >>>>> >>>>> not sure I am following, but the required fields should never be null >>>>> >>>>> >>>>> Now I'm not following. >>>>> >>>> >>>> :-) >>>> >>>> >>>>> Let's go through a scenario and see how each would work with your >>>>> method. Imagine there are currently values in every field. What fields need >>>>> values and what can be null when: >>>>> >>>>> I update a single required field? >>>>> I update a single optional field? >>>>> >>>> >>>> Well,when I update the FORM and hit ENTER (let's assume this is a PUT, >>>> just for now..), aren't the entire form values sent? >>>> >>>> So, any field that changed will be udpated, I think >>>> >>>> Now if you NULL out a required field, I'd imagine that is not allowed. >>>> >>>> >>>> So I guess I'm confused as to why there was any discussion of NULL >>>> fields being ignored then. If the form is filled in for the user, if they >>>> empty a field it should either fail (required field) or empty the value >>>> (optional field). >>>> >>> >>> +1 >>> >>> >>>> NULL should never just be ignored, right? >>>> >>> >>> I think, the "confusion" comes in..... what happens if (iOS Variant), >>> JUST the name is changed (note: the certificate FILE is required). >>> >>> >>> I guess that would be just fine... if (on the JUST iOSVariant.name is >>> changed), we do not bother with the certificate. >>> >>> We update the certificate ONLY if it is actually part of the "UPDATE >>> request". >>> >>> >>> I see. Yeah that's pretty standard. What I have done in my app building >>> past when dealing with files (certificate) is to show the current file name >>> in the UI and if the file field is left blank, ignore that in the update. >>> >>> >>> that seems to be a good way of doing it. we would still need to change >>> the logic on the endpoint method to ignore the certificate if its not >>> there, or use PATCH? >>> >> >> I'd say PUT (but I am not Roy Fielding ;-)) >> >> >> I would vote PATCH to be correct but would not cry if it's PUT I guess. >> > > yeah - good call. I guess PATCH does make sense [1]. > > > > > > [1] http://www.mnot.net/blog/2012/09/05/patch > > > > >> >> >> >>> >>> >>> the thing i'd be worried about when resending the cert bits, >>> >> >> do not do it :-) Only send IF a user really did select a file with the >> [input type:file] field, no ? >> >> >> +1 >> >> >> >>> would be that some bit might change in the transfer and F up everything >>> else >>> >>> >>> >>> -M >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> If we are to do partial updates like this though, I would say it >>>>>> should probably use http PATCH instead of PUT, right? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> (Well not sure it is a valid use case but you see my point) and >>>>>>> as you said we must then rethink user validation. >>>>>>> Other option is to split the update into more smaller specific >>>>>>> updates methods ... but not sure about this also. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>> >>>>>>>> the "variantID" is not a PK, but it's unique - so a new finder is >>>>>>>> what you need. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Should a user be able to update a certificate/key/channel once it >>>>>>>>> has been created. >>>>>>>> >>>>>>>> >>>>>>>> yes, they should be able to replace an outdated (or revoked) >>>>>>>> certificate, API etc. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> How would this affect any installations it might have? >>>>>>>>> >>>>>>>> >>>>>>>> Not at all. so if (speaking Androind) ... a new "project" is used >>>>>>>> - there is a new SenderID - that's more impact, since the actual mobile app >>>>>>>> needs to be updated, but again that's not really a concern for the push >>>>>>>> server >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> thoughts? >>>>>>>>> >>>>>>>>> -Luke >>>>>>>>> _______________________________________________ >>>>>>>>> aerogear-dev mailing list >>>>>>>>> aerogear-dev(a)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 >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> aerogear-dev mailing list >>>>>>>> aerogear-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> aerogear-dev mailing list >>>>>>> aerogear-dev(a)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 >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev(a)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 >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev(a)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 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)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 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev(a)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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev