On Tue, Jul 16, 2013 at 4:22 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
On Jul 16, 2013, at 10:13 AM, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
On Tue, Jul 16, 2013 at 4:12 PM, Lucas Holmquist <lholmqui(a)redhat.com>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> wrote:
>
> ok i'll create some JIRA's
>
> On Jul 16, 2013, at 9:23 AM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
>
>
>
> On Tue, Jul 16, 2013 at 3:15 PM, Kris Borchers <kris(a)redhat.com> wrote:
>
>>
>> On Jul 16, 2013, at 7:42 AM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>>
>>
>>
>> On Tue, Jul 16, 2013 at 2:39 PM, Lucas Holmquist
<lholmqui(a)redhat.com>wrote:
>>
>>>
>>> On Jul 16, 2013, at 8:35 AM, Kris Borchers <kris(a)redhat.com> wrote:
>>>
>>>
>>> On Jul 16, 2013, at 7:30 AM, Matthias Wessendorf <matzew(a)apache.org>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On Tue, Jul 16, 2013 at 2:23 PM, Kris Borchers <kris(a)redhat.com>
wrote:
>>>
>>>>
>>>> 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).
>>>>
>>>
>>> +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