So this is not really a design question.
So the admin console will allow developers/admins to "register" so they can log
into the UI, should there be a section in the UI that allows for user management? or is
this a separate thing? Probably not a priority atm, but just thinking out load
On Jul 2, 2013, at 10:21 AM, Hylke Bons <hbons(a)redhat.com> wrote:
Hold you horses, I barely had a day to work on them... :)
I'll post them as soon as possible.
Hylke
On 02/07/2013 14:50, Matthias Wessendorf wrote:
>
>
>
> On Mon, Jul 1, 2013 at 8:18 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
> HI,
>
> just wanted to see if there was any update to those wireframes yet
>
> I'd be interested as well :)
>
>
> -Matthias
>
>
>
> On Jun 28, 2013, at 1:06 PM, Hylke Bons <hbons(a)redhat.com> wrote:
>
>> Alright, so after a chat with Matthias on IRC about the potential use cases
I'm updating the wireframes with the requirement. I'll post an update here soon.
>>
>> Thanks,
>>
>> Hylke
>>
>>
>> On 28/06/2013 12:38, Matthias Wessendorf wrote:
>>>
>>>
>>>
>>> On Fri, Jun 28, 2013 at 1:35 PM, Lucas Holmquist <lholmqui(a)redhat.com>
wrote:
>>> perhaps a workflow explanation will clear things up a bit
>>>
>>>
>>> i log in to the admin console and the first screen should be where i create a
"Push Application", which isn't really an application, but just a grouping
name essentially.
>>>
>>> then under the "Push Applications" details, this is where we
actually create the "apps"( or the different variants of the grouping ). Each of
these would need there own certificate/googleApiKey.
>>>
>>> exactly
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Jun 28, 2013, at 7:28 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jun 28, 2013 at 1:16 PM, Hylke Bons <hbons(a)redhat.com>
wrote:
>>>> I'm not even sure we're talking about the same thing. :)
>>>>
>>>> Just to make sure, this is _not_ about the ID/Secret shown in the
wireframes for the app and its variants? (the variant ones show up in
"tooltips").
>>>>
>>>> Of course, every variant also has it's own variantID/secret
>>>>
>>>>
>>>>
>>>>
>>>> Hylke
>>>>
>>>>
>>>> On 28/06/2013 12:09, Matthias Wessendorf wrote:
>>>>>
>>>>>
>>>>> Still, we would you want to use different settings if the result,
>>>>> getting a message to the client, is the same?
>>>>>
>>>>> you lost me. Not sure what you are asking :)
>>>>>
>>>>> Are you concerned about the "payload" (message) is
represented differently ?
>>>>>
>>>>> If one PushApp has several variants:
>>>>> * HR-iOS-Tablet free
>>>>> * HR-iOS-Tablet paid
>>>>> * HR-iOS-Phone free
>>>>> * HR-Android-Phone paid
>>>>> * HR-Android-Watch free
>>>>>
>>>>>
>>>>> Each has it's OWN cert/key. Still if you send out something
like:
>>>>>
>>>>> curl -u "{PushApplicationID}:{MasterSecret}"
>>>>> -v -H "Accept: application/json" -H "Content-type:
application/json"
>>>>> -X POST
>>>>> -d '{"key":"value",
"alert":"HELLO!"}'
>>>>>
>>>>>
http://localhost:8080/ag-push/rest/sender/broadcast
>>>>>
>>>>> the message would be delivered to all clients - regardless of the
underlying "PushNetwork"
>>>>>
>>>>>
>>>>>
>>>>> Hylke
>>>>>
>>>>> _______________________________________________
>>>>> 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