On Jul 16, 2013, at 7:20 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Jul 16, 2013 at 2:14 PM, Kris Borchers <kris(a)redhat.com> wrote:
On Jul 16, 2013, at 7:10 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>
>
> On Tue, Jul 16, 2013 at 2:05 PM, Kris Borchers <kris(a)redhat.com> wrote:
>
> 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.
>
> 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). NULL should never just
be ignored, right?
>
>
>
> 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