Yes I tend to agree, we could stick to just one method/function to send
messages, you can pass "criterias" within the message to have the selective
send or just no cirterias and you have the "broadcast" behaviour.
But since this breaks the API, let's have the opinion of everyone on this
and then open JIRA etc ...
On Sat, Sep 14, 2013 at 2:43 PM, Kris Borchers <kborcher(a)redhat.com> wrote:
You can do the same thing with the other platforms as with
SimplePush, no?
Won't it work the same way by sending a selective send that includes all
necessary info for android, iOS and SimplePush but don't specify any
particular devices and just a category, you then get a broadcast to all
devices of all types for that category, correct? That is why I think the
broadcast is pointless.
On Sep 14, 2013, at 4:19, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Sat, Sep 14, 2013 at 9:32 AM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
> Yes but again when you want to do a broadcast to all the devices types
> and broadcast is not anymore available for SPS, does that mean that we must
> send 2 messages : one broadcast for "native" clients and a
"empty"
> selective send for SPS , not sure this is effective ? I must be missing
> something.
>
that's a good point
It would be two request to the UnifiedPush Server:
* broadcast for Android/iOS
* 'selective' send for the SimplePush client
I guess having the implicit 'broadcast' category does not hurt, since this
(as it is today) allows sending the broadcast to _all_ platforms via one
request
I think this does make sense.
I think (and I had similar thoughts) that Kris thinks the 'explicit' (JS
client side) registration for the broadcast category seems odd;
But now, after some more thoughts, I think it's a feature and we should
keep it
>
>
>
> On Fri, Sep 13, 2013 at 9:59 PM, Kris Borchers <kborcher(a)redhat.com>wrote:
>
>> The reasoning was that a broadcast can be done via selective if you just
>> send to a category and don't list any specific endpoints. To do a
>> broadcast, you specifically have to register a broadcast endpoint but then
>> your category doesn't have any meaning so it seems like more loss than gain
>> IMO.
>>
>> On Sep 13, 2013, at 7:11, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
>>
>> What is the reasoning behind this, i think i missed something
>> On Sep 13, 2013, at 3:57 AM, Sebastien Blanc <scm.blanc(a)gmail.com>
>> wrote:
>>
>> Concretely what does that means ? removing "simple-push" field from
the
>> broadcast message ?
>> The jira mention that we can achieve the same with a selective send but
>> on the client side when I want to send a broadcast and being agnostic from
>> the receiving clients I still want to use the (Unified) broadcast format.
>> So my question is will SimplePush Clients still receive my message if I
>> broadcast it (and not using the selective send) ?
>>
>>
>>
>>
>> On Fri, Sep 13, 2013 at 9:37 AM, Daniel Bevenius <
>> daniel.bevenius(a)gmail.com> wrote:
>>
>>> +1 I agree that it makes sense to remove broadcast now.
>>>
>>>
>>> On 13 September 2013 09:35, Matthias Wessendorf
<matzew(a)apache.org>wrote:
>>>
>>>> Following up on [1], to catch a wider audience, than JIRA.
>>>>
>>>> I do agree that it feels odd, for SimplePush.
>>>>
>>>> -M
>>>>
>>>> [1]
https://issues.jboss.org/browse/AGPUSH-323
>>>>
>>>> --
>>>> 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
>>
>>
>> _______________________________________________
>> 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