On Jul 16, 2013, at 3:05 AM, Matthias Wessendorf <matzew(a)apache.org> 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> wrote:
On Mon, Jul 15, 2013 at 8:34 PM, Lucas Holmquist <lholmqui(a)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
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.
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