1:51 p.m.
This document is devided in two sections:
- Native Push (Android and iOS)
- SimplePush (web-based Push)
<https://gist.github.com/matzew/98762c8d3f516e1abd38#native-push>Native Push
The Unified Push Server allows two different ways to send message to the
native Push API, of the supported devices:
- broadcast
- to all MobileVariants and their MobileVariant Instances (devices)
- to one specific MobileVariant and its MobileVariant Instances
(devices)
- seletive Send
<https://gist.github.com/matzew/98762c8d3f516e1abd38#broadcast>Broadcast
curl -v -H "Accept: application/json" -H "Content-type:
application/json"
-H "ag-push-application: {PushApplicationID}
-H "ag-mobile-variant: {MobileVariantID}
-X POST
-d '{"key":"value", "key2":"other value",
"alert":"HELLO!",
"sound":"default", "badge":7}'
http://localhost:8080/ag-push/rest/sender/broadcast
If the ag-push-application header is used, a message is send to a
PushApplication and *ALL*MobileVariantIncances will receive the message.
If the ag-mobile-variant header is used, a message is send to a particular
MobileVariant and *ALL* of its MobileVariantIncances will receive the
message.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format>Mes...
Format
The message format is very simple: A generic JSON map is used to send
messages to Android and iOS devices. The applications on the devices will
receive the JSON map and are responsible for performing a lookup to read
values of the given keys.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#ios-special-keys>iOS
special keys
If the JSON map contains on of the following reserved keywords, Apple
specific hooks will be invoked on the device:
- alert (triggers a dialog, displaying the value - no iOS API needs to
be invoked by the app developer)
- sound (plays a given sound - no iOS API needs to be invoked by the app
developer)
- badge (sets the value of the badge icon - no iOS API needs to be
invoked by the app developer)
<https://gist.github.com/matzew/98762c8d3f516e1abd38#android-special-keys&...
special keys
None! The JSON map is submitted as it is, directly to the device. There are
no Android specific keywords.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#selective-send>Sel...
Send
A message is send to a restricted number of MobileVariantIncances, based on
a given criteria. The following example shows the correspondent HTTP
interface:
curl -v -H "Accept: application/json" -H "Content-type:
application/json"
-X POST
-d '{
"alias" : ["user(a)account.com", "jay(a)redhat.org",
....],
"deviceType" : ["iPad", "AndroidTablet"],
"message": {"key":"value",
"key2":"other value", "alert":"HELLO!"}
}'
http://localhost:8080/ag-push/rest/sender/selected/{PushApplicationID}
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-1>M...
Format
Besides the actual payload the the API accepts a few *classifiers* to
select a subset of registered devices.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#query-component>Query
component
Currently the Server will support the following query criterias:
- alias: A list of email address (or usernames) to send messages to
*ALL* devices
of the users. Thealias needs to be stored, when the device is
registering itself with the server. See here for
details<https://github.com/matzew/ag-client-push-sdk/blob/master/push-...
- deviceType: A list of raw devices types that should receive the
message (e.g. Coupon only for iPad and AndroidTablets). The deviceType needs
to be stored, when the device is registering itself with the server. See
here for
details<https://github.com/matzew/ag-client-push-sdk/blob/master/push-...
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-payload>Me...
Payload
The message format is very simple: A generic JSON map is used to send
messages to Android and iOS devices. The applications on the devices will
receive the JSON map and are responsible for performing a lookup to read
values of the given keys. Like above, iOS specific keywords are honored.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#simplepush>SimplePush
The Unified Push Server allows two different ways to send message to
SimplePush-enabled devices:
- broadcast
- seletive Send
<https://gist.github.com/matzew/98762c8d3f516e1abd38#broadcast-1>Broadcast
Sends a message to all connected devices of a SimplePush variant. The
message (aka version) will be received on the *broadcast* channel (AeroGear
specific broadcast channel, not part of the official spec).
curl -v -H "Accept: application/json" -H "Content-type:
application/json"
-X POST
-d '{"version":1234}'
http://localhost:8080/ag-push/rest/sender/simplePush/broadcast/{SimplePus...
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-2>M...
Format
The message format is very simple: The version number is send to the
server, as a JSON object.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#selective-send-1>S...
Send
A message is send to a selected number of channels, connected against a
specific SimplePush variant
curl -v -H "Accept: application/json" -H "Content-type:
application/json"
-X POST
-d '{
"channelIDs":["someID", "moreID...."],
"version":1909
}'http://localhost:8080/ag-push/rest/sender/simplePush/selected/{SimplePushVariantID}
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-3>M...
Format
The message format is very simple: A JSON object, containing the actual
payload (version) and an array, containing all the different channels.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#discussion>Discussion
SimplePush and NativePush do have different APIs / endpoints. However,
that's mainly because the SimplePush is really.... simple.... and not 100%
compliant with the richer APIs for Android/iOS.
We *could* (later?) try to unify the API and simply *IGNORE* everything
besides the version, when talking toSimplePush Variant.
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
2:22 p.m.
Look good !
+1 to discuss later how to "unify" the message API
Regarding the message formats, don't we want to also define what the format
of the message responses are ?
On Mon, May 27, 2013 at 1:51 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
This document is devided in two sections:
- Native Push (Android and iOS)
- SimplePush (web-based Push)
<https://gist.github.com/matzew/98762c8d3f516e1abd38#native-push>Native
Push
The Unified Push Server allows two different ways to send message to the
native Push API, of the supported devices:
- broadcast
- to all MobileVariants and their MobileVariant Instances (devices)
- to one specific MobileVariant and its MobileVariant Instances
(devices)
- seletive Send
<https://gist.github.com/matzew/98762c8d3f516e1abd38#broadcast>Broadcast
curl -v -H "Accept: application/json" -H "Content-type:
application/json"
-H "ag-push-application: {PushApplicationID}
-H "ag-mobile-variant: {MobileVariantID}
-X POST
-d '{"key":"value", "key2":"other value",
"alert":"HELLO!", "sound":"default",
"badge":7}'
http://localhost:8080/ag-push/rest/sender/broadcast
If the ag-push-application header is used, a message is send to a
PushApplication and *ALL*MobileVariantIncances will receive the message.
If the ag-mobile-variant header is used, a message is send to a
particular MobileVariant and *ALL* of its MobileVariantIncances will
receive the message.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format>Mes...
Format
The message format is very simple: A generic JSON map is used to send
messages to Android and iOS devices. The applications on the devices will
receive the JSON map and are responsible for performing a lookup to read
values of the given keys.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#ios-special-keys>iOS
special keys
If the JSON map contains on of the following reserved keywords, Apple
specific hooks will be invoked on the device:
- alert (triggers a dialog, displaying the value - no iOS API needs to
be invoked by the app developer)
- sound (plays a given sound - no iOS API needs to be invoked by the
app developer)
- badge (sets the value of the badge icon - no iOS API needs to be
invoked by the app developer)
<https://gist.github.com/matzew/98762c8d3f516e1abd38#android-special-keys&...
special keys
None! The JSON map is submitted as it is, directly to the device. There
are no Android specific keywords.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#selective-send>Sel...
Send
A message is send to a restricted number of MobileVariantIncances, based
on a given criteria. The following example shows the correspondent HTTP
interface:
curl -v -H "Accept: application/json" -H "Content-type:
application/json"
-X POST
-d '{
"alias" : ["user(a)account.com", "jay(a)redhat.org",
....],
"deviceType" : ["iPad", "AndroidTablet"],
"message": {"key":"value",
"key2":"other value", "alert":"HELLO!"}
}'
http://localhost:8080/ag-push/rest/sender/selected/{PushApplicationID}
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-1>M...
Format
Besides the actual payload the the API accepts a few *classifiers* to
select a subset of registered devices.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#query-component>Query
component
Currently the Server will support the following query criterias:
- alias: A list of email address (or usernames) to send messages to *
ALL* devices of the users. Thealias needs to be stored, when the
device is registering itself with the server. See here for
details<https://github.com/matzew/ag-client-push-sdk/blob/master/push-...
- deviceType: A list of raw devices types that should receive the
message (e.g. Coupon only for iPad and AndroidTablets). The deviceType needs
to be stored, when the device is registering itself with the server. See
here for
details<https://github.com/matzew/ag-client-push-sdk/blob/master/push-...
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-payload>Me...
Payload
The message format is very simple: A generic JSON map is used to send
messages to Android and iOS devices. The applications on the devices will
receive the JSON map and are responsible for performing a lookup to read
values of the given keys. Like above, iOS specific keywords are honored.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#simplepush>
SimplePush
The Unified Push Server allows two different ways to send message to
SimplePush-enabled devices:
- broadcast
- seletive Send
<https://gist.github.com/matzew/98762c8d3f516e1abd38#broadcast-1>Broadcast
Sends a message to all connected devices of a SimplePush variant. The
message (aka version) will be received on the *broadcast* channel
(AeroGear specific broadcast channel, not part of the official spec).
curl -v -H "Accept: application/json" -H "Content-type:
application/json"
-X POST
-d '{"version":1234}'
http://localhost:8080/ag-push/rest/sender/simplePush/broadcast/{SimplePus...
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-2>M...
Format
The message format is very simple: The version number is send to the
server, as a JSON object.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#selective-send-1>S...
Send
A message is send to a selected number of channels, connected against a
specific SimplePush variant
curl -v -H "Accept: application/json" -H "Content-type:
application/json"
-X POST
-d '{
"channelIDs":["someID", "moreID...."],
"version":1909
}'http://localhost:8080/ag-push/rest/sender/simplePush/selected/{SimplePushVariantID}
<https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-3>M...
Format
The message format is very simple: A JSON object, containing the actual
payload (version) and an array, containing all the different channels.
<https://gist.github.com/matzew/98762c8d3f516e1abd38#discussion>
Discussion
SimplePush and NativePush do have different APIs / endpoints. However,
that's mainly because the SimplePush is really.... simple.... and not 100%
compliant with the richer APIs for Android/iOS.
We *could* (later?) try to unify the API and simply *IGNORE* everything
besides the version, when talking toSimplePush Variant.
--
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
2:26 p.m.
This is all fire and forget, there is no guarantee that the messages are
delivered.
Response would be: 200 "Job submitted"
On Mon, May 27, 2013 at 2:22 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
Look good !
+1 to discuss later how to "unify" the message API
Regarding the message formats, don't we want to also define what the
format of the message responses are ?
On Mon, May 27, 2013 at 1:51 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
> This document is devided in two sections:
>
> - Native Push (Android and iOS)
> - SimplePush (web-based Push)
>
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#native-push>Native
> Push
>
> The Unified Push Server allows two different ways to send message to the
> native Push API, of the supported devices:
>
> - broadcast
> - to all MobileVariants and their MobileVariant Instances (devices)
> - to one specific MobileVariant and its MobileVariant Instances
> (devices)
> - seletive Send
>
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#broadcast>Broadcast
>
> curl -v -H "Accept: application/json" -H "Content-type:
application/json"
> -H "ag-push-application: {PushApplicationID}
> -H "ag-mobile-variant: {MobileVariantID}
> -X POST
> -d '{"key":"value", "key2":"other
value", "alert":"HELLO!", "sound":"default",
"badge":7}'
> http://localhost:8080/ag-push/rest/sender/broadcast
>
> If the ag-push-application header is used, a message is send to a
> PushApplication and *ALL*MobileVariantIncances will receive the message.
>
> If the ag-mobile-variant header is used, a message is send to a
> particular MobileVariant and *ALL* of its MobileVariantIncances will
> receive the message.
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format>Mes...
> Format
>
> The message format is very simple: A generic JSON map is used to send
> messages to Android and iOS devices. The applications on the devices will
> receive the JSON map and are responsible for performing a lookup to read
> values of the given keys.
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#ios-special-keys>iOS
> special keys
>
> If the JSON map contains on of the following reserved keywords, Apple
> specific hooks will be invoked on the device:
>
> - alert (triggers a dialog, displaying the value - no iOS API needs
> to be invoked by the app developer)
> - sound (plays a given sound - no iOS API needs to be invoked by the
> app developer)
> - badge (sets the value of the badge icon - no iOS API needs to be
> invoked by the app developer)
>
>
<https://gist.github.com/matzew/98762c8d3f516e1abd38#android-special-keys&...
> special keys
>
> None! The JSON map is submitted as it is, directly to the device. There
> are no Android specific keywords.
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#selective-send>Sel...
> Send
>
> A message is send to a restricted number of MobileVariantIncances, based
> on a given criteria. The following example shows the correspondent HTTP
> interface:
>
> curl -v -H "Accept: application/json" -H "Content-type:
application/json"
> -X POST
>
> -d '{
> "alias" : ["user(a)account.com", "jay(a)redhat.org",
....],
>
> "deviceType" : ["iPad", "AndroidTablet"],
>
> "message": {"key":"value",
"key2":"other value", "alert":"HELLO!"}
> }'
> http://localhost:8080/ag-push/rest/sender/selected/{PushApplicationID}
>
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-1>M...
> Format
>
> Besides the actual payload the the API accepts a few *classifiers* to
> select a subset of registered devices.
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#query-component>Query
> component
>
> Currently the Server will support the following query criterias:
>
> - alias: A list of email address (or usernames) to send messages to *
> ALL* devices of the users. Thealias needs to be stored, when the
> device is registering itself with the server. See here for
details<https://github.com/matzew/ag-client-push-sdk/blob/master/push-...
> - deviceType: A list of raw devices types that should receive the
> message (e.g. Coupon only for iPad and AndroidTablets). The deviceType needs
> to be stored, when the device is registering itself with the server. See
> here for
details<https://github.com/matzew/ag-client-push-sdk/blob/master/push-...
>
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#message-payload>Me...
> Payload
>
> The message format is very simple: A generic JSON map is used to send
> messages to Android and iOS devices. The applications on the devices will
> receive the JSON map and are responsible for performing a lookup to read
> values of the given keys. Like above, iOS specific keywords are honored.
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#simplepush>
> SimplePush
>
> The Unified Push Server allows two different ways to send message to
> SimplePush-enabled devices:
>
> - broadcast
> - seletive Send
>
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#broadcast-1>
> Broadcast
>
> Sends a message to all connected devices of a SimplePush variant. The
> message (aka version) will be received on the *broadcast* channel
> (AeroGear specific broadcast channel, not part of the official spec).
>
> curl -v -H "Accept: application/json" -H "Content-type:
application/json"
>
> -X POST
> -d '{"version":1234}'
> http://localhost:8080/ag-push/rest/sender/simplePush/broadcast/{SimplePus...
>
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-2>M...
> Format
>
> The message format is very simple: The version number is send to the
> server, as a JSON object.
>
<https://gist.github.com/matzew/98762c8d3f516e1abd38#selective-send-1>S...
> Send
>
> A message is send to a selected number of channels, connected against a
> specific SimplePush variant
>
> curl -v -H "Accept: application/json" -H "Content-type:
application/json"
> -X POST
> -d '{
> "channelIDs":["someID", "moreID...."],
> "version":1909
>
}'http://localhost:8080/ag-push/rest/sender/simplePush/selected/{SimplePushVariantID}
>
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#message-format-3>M...
> Format
>
> The message format is very simple: A JSON object, containing the actual
> payload (version) and an array, containing all the different channels.
> <https://gist.github.com/matzew/98762c8d3f516e1abd38#discussion>
> Discussion
>
> SimplePush and NativePush do have different APIs / endpoints. However,
> that's mainly because the SimplePush is really.... simple.... and not 100%
> compliant with the richer APIs for Android/iOS.
>
> We *could* (later?) try to unify the API and simply *IGNORE* everything
> besides the version, when talking toSimplePush Variant.
>
> --
> 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
11:36 p.m.
Unifying the APIs shouldn't be hard and could probably happen sooner rather than
later, IMO. As far as the client goes, if you send extra info beyond the version it will
just be ignored. Though, it would be better to not send the extra info to keep payload
small. I guess the issue would be on the SPS side and if it can handle receiving and
ignoring the extra info.
On May 27, 2013, at 14:06, Daniel Passos <daniel(a)passos.me> wrote:
Very nice!
+1 to discuss later how to "unify" APIs
Matthias Wessendorf wrote:
> We /could/ (later?) try to unify the API and simply
> *IGNORE* everything besides the version, when talking
> to|SimplePush| Variant.
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
midnight
When doing selective push query, is there any overlap between mobile
variant (which I understand like mobile type which contains certificates)
and device type?
Both aimed at defining categories.
Are those categories defined and fixed in the spec or can they be extended?
Can we do a selective push based on mobileType=mobile variant and
alias=john@gmail?
On 27 May 2013 23:36, Kris Borchers <kborcher(a)redhat.com> wrote:
Unifying the APIs shouldn't be hard and could probably happen
sooner
rather than later, IMO. As far as the client goes, if you send extra info
beyond the version it will just be ignored. Though, it would be better to
not send the extra info to keep payload small. I guess the issue would be
on the SPS side and if it can handle receiving and ignoring the extra info.
On May 27, 2013, at 14:06, Daniel Passos <daniel(a)passos.me> wrote:
> Very nice!
> +1 to discuss later how to "unify" APIs
>
> Matthias Wessendorf wrote:
>> We /could/ (later?) try to unify the API and simply
>> *IGNORE* everything besides the version, when talking
>> to|SimplePush| Variant.
> _______________________________________________
> 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
6:03 a.m.
On Mon, May 27, 2013 at 01:51:46PM +0200, Matthias Wessendorf wrote:
We *could* (later?) try to unify the API and simply *IGNORE*
everything
besides the version, when talking toSimplePush Variant.
This feels like trying to
put a square peg on a round hole, but yeah,
let's discuss this later :P
--
qmx
6:29 a.m.
I guess the issue would be on the SPS side and if it can handle
receiving
and ignoring the extra info.
This should not be a problemen but let me add a test for this and make sure:
https://issues.jboss.org/browse/AGPUSH-54
On 27 May 2013 23:36, Kris Borchers <kborcher(a)redhat.com> wrote:
Unifying the APIs shouldn't be hard and could probably happen
sooner
rather than later, IMO. As far as the client goes, if you send extra info
beyond the version it will just be ignored. Though, it would be better to
not send the extra info to keep payload small. I guess the issue would be
on the SPS side and if it can handle receiving and ignoring the extra info.
On May 27, 2013, at 14:06, Daniel Passos <daniel(a)passos.me> wrote:
> Very nice!
> +1 to discuss later how to "unify" APIs
>
> Matthias Wessendorf wrote:
>> We /could/ (later?) try to unify the API and simply
>> *IGNORE* everything besides the version, when talking
>> to|SimplePush| Variant.
> _______________________________________________
> 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
8:35 a.m.
On Mon, May 27, 2013 at 11:36 PM, Kris Borchers <kborcher(a)redhat.com> wrote:
Unifying the APIs shouldn't be hard and could probably happen
sooner
rather than later, IMO. As far as the client goes, if you send extra info
beyond the version it will just be ignored.
if we do ignore the extra info, than it would be ignored on the UnifiedPush
side.
If the SimplePush variant type, the server would just send the version, and
not everything else. I don't see a reason to send the entire message,
unfiltered, to the SP-server
Though, it would be better to not send the extra info to keep
payload
small. I guess the issue would be on the SPS side and if it can handle
receiving and ignoring the extra info.
On May 27, 2013, at 14:06, Daniel Passos <daniel(a)passos.me> wrote:
> Very nice!
> +1 to discuss later how to "unify" APIs
>
> Matthias Wessendorf wrote:
>> We /could/ (later?) try to unify the API and simply
>> *IGNORE* everything besides the version, when talking
>> to|SimplePush| Variant.
> _______________________________________________
> 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
8:43 a.m.
On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
When doing selective push query, is there any overlap between mobile
variant (which I understand like mobile type which contains certificates)
and device type?
MobileVariant (or call it type) is something like "Android", or
"iOS".
deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android Table",
"Andrpid phone", android what not
Sure.... ideally there are several variants:
- iOS iPhone 5 optimised app in the app store
- iOS iPhone 4s optimised app in the app store
- iOS iPhone 3 optimised app in the app store
- iOS iPad mini optimised app in the app store
etc :)
But, if there is only one variant, it's totally valid to install an iOS
application (from the appstore), on an iPad and an iPhone;
Both aimed at defining categories.
Are those categories defined and fixed in the spec or can they be extended?
I don't understand categories, here
Can we do a selective push based on mobileType=mobile variant and
alias=john@gmail?
deviceType and alias should be possible;
It should be also possible to combine that with a variant
==> variant: iOS (since we have only one iOS varaint) + deviceType:iPadMini
+ alias: mwessendorf
I need to add that to the "Message Format" / spec
On 27 May 2013 23:36, Kris Borchers <kborcher(a)redhat.com> wrote:
> Unifying the APIs shouldn't be hard and could probably happen sooner
> rather than later, IMO. As far as the client goes, if you send extra info
> beyond the version it will just be ignored. Though, it would be better to
> not send the extra info to keep payload small. I guess the issue would be
> on the SPS side and if it can handle receiving and ignoring the extra info.
>
> On May 27, 2013, at 14:06, Daniel Passos <daniel(a)passos.me> wrote:
>
> > Very nice!
> > +1 to discuss later how to "unify" APIs
> >
> > Matthias Wessendorf wrote:
> >> We /could/ (later?) try to unify the API and simply
> >> *IGNORE* everything besides the version, when talking
> >> to|SimplePush| Variant.
> > _______________________________________________
> > 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
8:48 a.m.
TYPO:
==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPadMini + alias: mwessendorf
or
==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPhone + alias: mwessendorf
On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
> When doing selective push query, is there any overlap between mobile
> variant (which I understand like mobile type which contains certificates)
> and device type?
>
MobileVariant (or call it type) is something like "Android", or
"iOS".
deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android Table",
"Andrpid phone", android what not
Sure.... ideally there are several variants:
- iOS iPhone 5 optimised app in the app store
- iOS iPhone 4s optimised app in the app store
- iOS iPhone 3 optimised app in the app store
- iOS iPad mini optimised app in the app store
etc :)
But, if there is only one variant, it's totally valid to install an iOS
application (from the appstore), on an iPad and an iPhone;
> Both aimed at defining categories.
> Are those categories defined and fixed in the spec or can they be
> extended?
>
I don't understand categories, here
> Can we do a selective push based on mobileType=mobile variant and
> alias=john@gmail?
>
deviceType and alias should be possible;
It should be also possible to combine that with a variant
==> variant: iOS (since we have only one iOS varaint) +
deviceType:iPadMini + alias: mwessendorf
I need to add that to the "Message Format" / spec
>
>
> On 27 May 2013 23:36, Kris Borchers <kborcher(a)redhat.com> wrote:
>
>> Unifying the APIs shouldn't be hard and could probably happen sooner
>> rather than later, IMO. As far as the client goes, if you send extra info
>> beyond the version it will just be ignored. Though, it would be better to
>> not send the extra info to keep payload small. I guess the issue would be
>> on the SPS side and if it can handle receiving and ignoring the extra info.
>>
>> On May 27, 2013, at 14:06, Daniel Passos <daniel(a)passos.me> wrote:
>>
>> > Very nice!
>> > +1 to discuss later how to "unify" APIs
>> >
>> > Matthias Wessendorf wrote:
>> >> We /could/ (later?) try to unify the API and simply
>> >> *IGNORE* everything besides the version, when talking
>> >> to|SimplePush| Variant.
>> > _______________________________________________
>> > 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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
8:51 a.m.
On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
TYPO:
==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPadMini + alias: mwessendorf
or
==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPhone + alias: mwessendorf
On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>
>
> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
>
>> When doing selective push query, is there any overlap between mobile
>> variant (which I understand like mobile type which contains certificates)
>> and device type?
>>
>
> MobileVariant (or call it type) is something like "Android", or
"iOS".
> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android Table",
> "Andrpid phone", android what not
>
>
> Sure.... ideally there are several variants:
> - iOS iPhone 5 optimised app in the app store
> - iOS iPhone 4s optimised app in the app store
> - iOS iPhone 3 optimised app in the app store
> - iOS iPad mini optimised app in the app store
> etc :)
>
> But, if there is only one variant, it's totally valid to install an iOS
> application (from the appstore), on an iPad and an iPhone;
>
>
>> Both aimed at defining categories.
>> Are those categories defined and fixed in the spec or can they be
>> extended?
>>
>
>
> I don't understand categories, here
>
>
>> Can we do a selective push based on mobileType=mobile variant and
>> alias=john@gmail?
>>
>
> deviceType and alias should be possible;
> It should be also possible to combine that with a variant
>
> ==> variant: iOS (since we have only one iOS varaint) +
> deviceType:iPadMini + alias: mwessendorf
>
> I need to add that to the "Message Format" / spec
>
>
>
>>
>>
>> On 27 May 2013 23:36, Kris Borchers <kborcher(a)redhat.com> wrote:
>>
>>> Unifying the APIs shouldn't be hard and could probably happen sooner
>>> rather than later, IMO. As far as the client goes, if you send extra info
>>> beyond the version it will just be ignored. Though, it would be better to
>>> not send the extra info to keep payload small. I guess the issue would be
>>> on the SPS side and if it can handle receiving and ignoring the extra info.
>>>
>>> On May 27, 2013, at 14:06, Daniel Passos <daniel(a)passos.me> wrote:
>>>
>>> > Very nice!
>>> > +1 to discuss later how to "unify" APIs
>>> >
>>> > Matthias Wessendorf wrote:
>>> >> We /could/ (later?) try to unify the API and simply
>>> >> *IGNORE* everything besides the version, when talking
>>> >> to|SimplePush| Variant.
>>> > _______________________________________________
>>> > 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
>
--
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
8:51 a.m.
in selective push is:
==> variant: iOS + alias: mwessendorf
a valid criteria too?
On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
> TYPO:
> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
> deviceType:iPadMini + alias: mwessendorf
> or
> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
> deviceType:iPhone + alias: mwessendorf
>
>
>
>
>
> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>>
>>
>>
>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych
<corinnekrych(a)gmail.com>wrote:
>>
>>> When doing selective push query, is there any overlap between mobile
>>> variant (which I understand like mobile type which contains certificates)
>>> and device type?
>>>
>>
>> MobileVariant (or call it type) is something like "Android", or
"iOS".
>> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android
>> Table", "Andrpid phone", android what not
>>
>>
>> Sure.... ideally there are several variants:
>> - iOS iPhone 5 optimised app in the app store
>> - iOS iPhone 4s optimised app in the app store
>> - iOS iPhone 3 optimised app in the app store
>> - iOS iPad mini optimised app in the app store
>> etc :)
>>
>> But, if there is only one variant, it's totally valid to install an iOS
>> application (from the appstore), on an iPad and an iPhone;
>>
>>
>>> Both aimed at defining categories.
>>> Are those categories defined and fixed in the spec or can they be
>>> extended?
>>>
>>
>>
>> I don't understand categories, here
>>
>>
>>> Can we do a selective push based on mobileType=mobile variant and
>>> alias=john@gmail?
>>>
>>
>> deviceType and alias should be possible;
>> It should be also possible to combine that with a variant
>>
>> ==> variant: iOS (since we have only one iOS varaint) +
>> deviceType:iPadMini + alias: mwessendorf
>>
>> I need to add that to the "Message Format" / spec
>>
>>
>>
>>>
>>>
>>> On 27 May 2013 23:36, Kris Borchers <kborcher(a)redhat.com> wrote:
>>>
>>>> Unifying the APIs shouldn't be hard and could probably happen sooner
>>>> rather than later, IMO. As far as the client goes, if you send extra
info
>>>> beyond the version it will just be ignored. Though, it would be better
to
>>>> not send the extra info to keep payload small. I guess the issue would
be
>>>> on the SPS side and if it can handle receiving and ignoring the extra
info.
>>>>
>>>> On May 27, 2013, at 14:06, Daniel Passos <daniel(a)passos.me> wrote:
>>>>
>>>> > Very nice!
>>>> > +1 to discuss later how to "unify" APIs
>>>> >
>>>> > Matthias Wessendorf wrote:
>>>> >> We /could/ (later?) try to unify the API and simply
>>>> >> *IGNORE* everything besides the version, when talking
>>>> >> to|SimplePush| Variant.
>>>> > _______________________________________________
>>>> > 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
>>
>
>
>
> --
> 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
>
8:53 a.m.
On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
in selective push is:
==> variant: iOS + alias: mwessendorf
a valid criteria too?
yes. let me update the related doc(s)
On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>
>
>
> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>> TYPO:
>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
>> deviceType:iPadMini + alias: mwessendorf
>> or
>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
>> deviceType:iPhone + alias: mwessendorf
>>
>>
>>
>>
>>
>> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf
<matzew(a)apache.org>wrote:
>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com
>>> > wrote:
>>>
>>>> When doing selective push query, is there any overlap between mobile
>>>> variant (which I understand like mobile type which contains
certificates)
>>>> and device type?
>>>>
>>>
>>> MobileVariant (or call it type) is something like "Android", or
"iOS".
>>> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android
>>> Table", "Andrpid phone", android what not
>>>
>>>
>>> Sure.... ideally there are several variants:
>>> - iOS iPhone 5 optimised app in the app store
>>> - iOS iPhone 4s optimised app in the app store
>>> - iOS iPhone 3 optimised app in the app store
>>> - iOS iPad mini optimised app in the app store
>>> etc :)
>>>
>>> But, if there is only one variant, it's totally valid to install an iOS
>>> application (from the appstore), on an iPad and an iPhone;
>>>
>>>
>>>> Both aimed at defining categories.
>>>> Are those categories defined and fixed in the spec or can they be
>>>> extended?
>>>>
>>>
>>>
>>> I don't understand categories, here
>>>
>>>
>>>> Can we do a selective push based on mobileType=mobile variant and
>>>> alias=john@gmail?
>>>>
>>>
>>> deviceType and alias should be possible;
>>> It should be also possible to combine that with a variant
>>>
>>> ==> variant: iOS (since we have only one iOS varaint) +
>>> deviceType:iPadMini + alias: mwessendorf
>>>
>>> I need to add that to the "Message Format" / spec
>>>
>>>
>>>
>>>>
>>>>
>>>> On 27 May 2013 23:36, Kris Borchers <kborcher(a)redhat.com> wrote:
>>>>
>>>>> Unifying the APIs shouldn't be hard and could probably happen
sooner
>>>>> rather than later, IMO. As far as the client goes, if you send extra
info
>>>>> beyond the version it will just be ignored. Though, it would be
better to
>>>>> not send the extra info to keep payload small. I guess the issue
would be
>>>>> on the SPS side and if it can handle receiving and ignoring the extra
info.
>>>>>
>>>>> On May 27, 2013, at 14:06, Daniel Passos <daniel(a)passos.me>
wrote:
>>>>>
>>>>> > Very nice!
>>>>> > +1 to discuss later how to "unify" APIs
>>>>> >
>>>>> > Matthias Wessendorf wrote:
>>>>> >> We /could/ (later?) try to unify the API and simply
>>>>> >> *IGNORE* everything besides the version, when talking
>>>>> >> to|SimplePush| Variant.
>>>>> > _______________________________________________
>>>>> > 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
>>>
>>
>>
>>
>> --
>> 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
5:31 p.m.
something that i was thinking about after doing some examples is that i'm not sure how
i feel about using the PK's of each table as the identifier to register/broadcast
clients.
We are sort of giving meaning to data that really shouldn't have meaning. it should
really only be used to identify the row. It might be better to have another key on each
table/object that is the identifier.
So in one of the examples i did, the app on the device will register the device with the
push server, but i needed to also include the id of the variant instance
i guess i'm thinking if someone migrates their database, these keys could get messed
up.
wdyt?
On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <corinnekrych(a)gmail.com> wrote:
in selective push is:
==> variant: iOS + alias: mwessendorf
a valid criteria too?
yes. let me update the related doc(s)
On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
TYPO:
==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPadMini + alias: mwessendorf
or
==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPhone + alias: mwessendorf
On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com> wrote:
When doing selective push query, is there any overlap between mobile variant (which I
understand like mobile type which contains certificates) and device type?
MobileVariant (or call it type) is something like "Android", or
"iOS".
deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android Table",
"Andrpid phone", android what not
Sure.... ideally there are several variants:
- iOS iPhone 5 optimised app in the app store
- iOS iPhone 4s optimised app in the app store
- iOS iPhone 3 optimised app in the app store
- iOS iPad mini optimised app in the app store
etc :)
But, if there is only one variant, it's totally valid to install an iOS application
(from the appstore), on an iPad and an iPhone;
Both aimed at defining categories.
Are those categories defined and fixed in the spec or can they be extended?
I don't understand categories, here
Can we do a selective push based on mobileType=mobile variant and alias=john@gmail?
deviceType and alias should be possible;
It should be also possible to combine that with a variant
==> variant: iOS (since we have only one iOS varaint) + deviceType:iPadMini + alias:
mwessendorf
I need to add that to the "Message Format" / spec
On 27 May 2013 23:36, Kris Borchers <kborcher(a)redhat.com> wrote:
Unifying the APIs shouldn't be hard and could probably happen sooner rather than
later, IMO. As far as the client goes, if you send extra info beyond the version it will
just be ignored. Though, it would be better to not send the extra info to keep payload
small. I guess the issue would be on the SPS side and if it can handle receiving and
ignoring the extra info.
On May 27, 2013, at 14:06, Daniel Passos <daniel(a)passos.me> wrote:
> Very nice!
> +1 to discuss later how to "unify" APIs
>
> Matthias Wessendorf wrote:
>> We /could/ (later?) try to unify the API and simply
>> *IGNORE* everything besides the version, when talking
>> to|SimplePush| Variant.
> _______________________________________________
> 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
--
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
6:24 p.m.
somehow the device needs to say: "I belong to android variant"
besides the @Id /PK, we can have a second field / column that represents:
* PushAppID
* VariantID
Was that your question?
On Friday, May 31, 2013, Lucas Holmquist wrote:
something that i was thinking about after doing some examples is that
i'm
not sure how i feel about using the PK's of each table as the identifier to
register/broadcast clients.
We are sort of giving meaning to data that really shouldn't have meaning.
it should really only be used to identify the row. It might be better to
have another key on each table/object that is the identifier.
So in one of the examples i did, the app on the device will register the
device with the push server, but i needed to also include the id of the
variant instance
i guess i'm thinking if someone migrates their database, these keys could
get messed up.
wdyt?
On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
in selective push is:
==> variant: iOS + alias: mwessendorf
a valid criteria too?
yes. let me update the related doc(s)
On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
TYPO:
==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPadMini + alias: mwessendorf
or
==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPhone + alias: mwessendorf
On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
When doing selective push query, is there any overlap between mobile
variant (which I understand like mobile type which contains certificates)
and device type?
MobileVariant (or call it type) is something like "Android", or
"iOS".
deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android Table",
"Andrpid phone", android what not
Sure.... ideally there are several variants:
- iOS iPhone 5 optimised app in the app store
- iOS iPhone 4s optimised app in the app store
- iOS iPhone 3 optimised app in the app store
- iOS iPad mini optimised app in the app store
etc :)
But, if there is only one variant, it's totally valid to install an iOS
application (from the appstore), on an iPad and an iPhone;
Both aimed at defining categories.
Are those categories defined and fixed in the spec or can they be
extended?
I don't understand categories, here
Can we do a selective push based on mobileType=mobile variant and
alias=john@gmail?
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
6:25 p.m.
Sent from my iPhone
On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
somehow the device needs to say: "I belong to android
variant"
besides the @Id /PK, we can have a second field / column that represents:
* PushAppID
* VariantID
Yup. Having these would solve that
Was that your question?
On Friday, May 31, 2013, Lucas Holmquist wrote:
> something that i was thinking about after doing some examples is that i'm not
sure how i feel about using the PK's of each table as the identifier to
register/broadcast clients.
>
> We are sort of giving meaning to data that really shouldn't have meaning. it
should really only be used to identify the row. It might be better to have another key on
each table/object that is the identifier.
>
> So in one of the examples i did, the app on the device will register the device with
the push server, but i needed to also include the id of the variant instance
>
> i guess i'm thinking if someone migrates their database, these keys could get
messed up.
>
>
> wdyt?
>
>
> On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>>
>>
>>
>> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
>> in selective push is:
>> ==> variant: iOS + alias: mwessendorf
>> a valid criteria too?
>>
>>
>> yes. let me update the related doc(s)
>>
>>
>>
>> On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>>
>>
>>
>> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
>> TYPO:
>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPadMini + alias: mwessendorf
>> or
>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPhone + alias: mwessendorf
>>
>>
>>
>>
>>
>> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>>
>>
>>
>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
>> When doing selective push query, is there any overlap between mobile variant
(which I understand like mobile type which contains certificates) and device type?
>>
>> MobileVariant (or call it type) is something like "Android", or
"iOS".
>> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android
Table", "Andrpid phone", android what not
>>
>>
>> Sure.... ideally there are several variants:
>> - iOS iPhone 5 optimised app in the app store
>> - iOS iPhone 4s optimised app in the app store
>> - iOS iPhone 3 optimised app in the app store
>> - iOS iPad mini optimised app in the app store
>> etc :)
>>
>> But, if there is only one variant, it's totally valid to install an iOS
application (from the appstore), on an iPad and an iPhone;
>>
>> Both aimed at defining categories.
>> Are those categories defined and fixed in the spec or can they be extended?
>>
>>
>> I don't understand categories, here
>>
>> Can we do a selective push based on mobileType=mobile variant and
alias=john@gmail?
--
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
6:39 p.m.
https://issues.jboss.org/browse/AGPUSH-86
On Fri, May 31, 2013 at 6:25 PM, Luke Holmquist <lholmqui(a)redhat.com> wrote:
Sent from my iPhone
On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
somehow the device needs to say: "I belong to android variant"
besides the @Id /PK, we can have a second field / column that represents:
* PushAppID
* VariantID
Yup. Having these would solve that
Was that your question?
On Friday, May 31, 2013, Lucas Holmquist wrote:
> something that i was thinking about after doing some examples is that i'm
> not sure how i feel about using the PK's of each table as the identifier to
> register/broadcast clients.
>
> We are sort of giving meaning to data that really shouldn't have meaning.
> it should really only be used to identify the row. It might be better to
> have another key on each table/object that is the identifier.
>
> So in one of the examples i did, the app on the device will register the
> device with the push server, but i needed to also include the id of the
> variant instance
>
> i guess i'm thinking if someone migrates their database, these keys
> could get messed up.
>
>
> wdyt?
>
>
> On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
>
>
>
> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
>
> in selective push is:
> ==> variant: iOS + alias: mwessendorf
> a valid criteria too?
>
>
>
> yes. let me update the related doc(s)
>
>
>
>
> On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>
>
>
>
> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
> TYPO:
> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
> deviceType:iPadMini + alias: mwessendorf
> or
> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
> deviceType:iPhone + alias: mwessendorf
>
>
>
>
>
> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <matzew(a)apache.org>wrote:
>
>
>
>
> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
>
> When doing selective push query, is there any overlap between mobile
> variant (which I understand like mobile type which contains certificates)
> and device type?
>
>
> MobileVariant (or call it type) is something like "Android", or
"iOS".
> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android Table",
> "Andrpid phone", android what not
>
>
> Sure.... ideally there are several variants:
> - iOS iPhone 5 optimised app in the app store
> - iOS iPhone 4s optimised app in the app store
> - iOS iPhone 3 optimised app in the app store
> - iOS iPad mini optimised app in the app store
> etc :)
>
> But, if there is only one variant, it's totally valid to install an iOS
> application (from the appstore), on an iPad and an iPhone;
>
>
> Both aimed at defining categories.
> Are those categories defined and fixed in the spec or can they be
> extended?
>
>
>
> I don't understand categories, here
>
>
> Can we do a selective push based on mobileType=mobile variant and
> alias=john@gmail?
>
>
>
--
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
6:45 p.m.
plus plus
On May 31, 2013, at 12:39 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
https://issues.jboss.org/browse/AGPUSH-86
On Fri, May 31, 2013 at 6:25 PM, Luke Holmquist <lholmqui(a)redhat.com> wrote:
Sent from my iPhone
On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> somehow the device needs to say: "I belong to android variant"
>
> besides the @Id /PK, we can have a second field / column that represents:
> * PushAppID
> * VariantID
>
Yup. Having these would solve that
>
> Was that your question?
>
> On Friday, May 31, 2013, Lucas Holmquist wrote:
> something that i was thinking about after doing some examples is that i'm not
sure how i feel about using the PK's of each table as the identifier to
register/broadcast clients.
>
> We are sort of giving meaning to data that really shouldn't have meaning. it
should really only be used to identify the row. It might be better to have another key on
each table/object that is the identifier.
>
> So in one of the examples i did, the app on the device will register the device with
the push server, but i needed to also include the id of the variant instance
>
> i guess i'm thinking if someone migrates their database, these keys could get
messed up.
>
>
> wdyt?
>
>
> On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>>
>>
>>
>> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
>> in selective push is:
>> ==> variant: iOS + alias: mwessendorf
>> a valid criteria too?
>>
>>
>> yes. let me update the related doc(s)
>>
>>
>>
>> On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>>
>>
>>
>> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
>> TYPO:
>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPadMini + alias: mwessendorf
>> or
>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPhone + alias: mwessendorf
>>
>>
>>
>>
>>
>> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>>
>>
>>
>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
>> When doing selective push query, is there any overlap between mobile variant
(which I understand like mobile type which contains certificates) and device type?
>>
>> MobileVariant (or call it type) is something like "Android", or
"iOS".
>> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android
Table", "Andrpid phone", android what not
>>
>>
>> Sure.... ideally there are several variants:
>> - iOS iPhone 5 optimised app in the app store
>> - iOS iPhone 4s optimised app in the app store
>> - iOS iPhone 3 optimised app in the app store
>> - iOS iPad mini optimised app in the app store
>> etc :)
>>
>> But, if there is only one variant, it's totally valid to install an iOS
application (from the appstore), on an iPad and an iPhone;
>>
>> Both aimed at defining categories.
>> Are those categories defined and fixed in the spec or can they be extended?
>>
>>
>> I don't understand categories, here
>>
>> Can we do a selective push based on mobileType=mobile variant and
alias=john@gmail?
>>
>
>
> --
> 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
11:23 a.m.
+ 666
Envoyé de mon iPhone
Le May 31, 2013 à 18:45, Lucas Holmquist <lholmqui(a)redhat.com> a écrit :
plus plus
On May 31, 2013, at 12:39 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> https://issues.jboss.org/browse/AGPUSH-86
>
>
> On Fri, May 31, 2013 at 6:25 PM, Luke Holmquist <lholmqui(a)redhat.com> wrote:
>
>
> Sent from my iPhone
>
> On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>> somehow the device needs to say: "I belong to android variant"
>>
>> besides the @Id /PK, we can have a second field / column that represents:
>> * PushAppID
>> * VariantID
>>
>
> Yup. Having these would solve that
>
>
>>
>> Was that your question?
>>
>> On Friday, May 31, 2013, Lucas Holmquist wrote:
>> something that i was thinking about after doing some examples is that i'm not
sure how i feel about using the PK's of each table as the identifier to
register/broadcast clients.
>>
>> We are sort of giving meaning to data that really shouldn't have meaning. it
should really only be used to identify the row. It might be better to have another key on
each table/object that is the identifier.
>>
>> So in one of the examples i did, the app on the device will register the device
with the push server, but i needed to also include the id of the variant instance
>>
>> i guess i'm thinking if someone migrates their database, these keys could
get messed up.
>>
>>
>> wdyt?
>>
>>
>> On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
>>> in selective push is:
>>> ==> variant: iOS + alias: mwessendorf
>>> a valid criteria too?
>>>
>>>
>>> yes. let me update the related doc(s)
>>>
>>>
>>>
>>> On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>>>
>>>
>>>
>>> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>> TYPO:
>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPadMini + alias: mwessendorf
>>> or
>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPhone + alias: mwessendorf
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf
<matzew(a)apache.org> wrote:
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych
<corinnekrych(a)gmail.com> wrote:
>>> When doing selective push query, is there any overlap between mobile variant
(which I understand like mobile type which contains certificates) and device type?
>>>
>>> MobileVariant (or call it type) is something like "Android", or
"iOS".
>>> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android
Table", "Andrpid phone", android what not
>>>
>>>
>>> Sure.... ideally there are several variants:
>>> - iOS iPhone 5 optimised app in the app store
>>> - iOS iPhone 4s optimised app in the app store
>>> - iOS iPhone 3 optimised app in the app store
>>> - iOS iPad mini optimised app in the app store
>>> etc :)
>>>
>>> But, if there is only one variant, it's totally valid to install an iOS
application (from the appstore), on an iPad and an iPhone;
>>>
>>> Both aimed at defining categories.
>>> Are those categories defined and fixed in the spec or can they be extended?
>>>
>>>
>>> I don't understand categories, here
>>>
>>> Can we do a selective push based on mobileType=mobile variant and
alias=john@gmail?
>>>
>>
>>
>> --
>> 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
3:17 p.m.
Luke
once this landed, it will be "pushApplicationID" and "variantID" - the
ID
is than meaningless (at least for PushEE server).
-M
On Fri, May 31, 2013 at 6:45 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
plus plus
On May 31, 2013, at 12:39 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
https://issues.jboss.org/browse/AGPUSH-86
On Fri, May 31, 2013 at 6:25 PM, Luke Holmquist <lholmqui(a)redhat.com>wrote:
>
>
> Sent from my iPhone
>
> On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
> somehow the device needs to say: "I belong to android variant"
>
> besides the @Id /PK, we can have a second field / column that represents:
> * PushAppID
> * VariantID
>
> Yup. Having these would solve that
>
>
>
> Was that your question?
>
> On Friday, May 31, 2013, Lucas Holmquist wrote:
>
>> something that i was thinking about after doing some examples is that
>> i'm not sure how i feel about using the PK's of each table as the
>> identifier to register/broadcast clients.
>>
>> We are sort of giving meaning to data that really shouldn't have
>> meaning. it should really only be used to identify the row. It might be
>> better to have another key on each table/object that is the identifier.
>>
>> So in one of the examples i did, the app on the device will register
>> the device with the push server, but i needed to also include the id of
>> the variant instance
>>
>> i guess i'm thinking if someone migrates their database, these keys
>> could get messed up.
>>
>>
>> wdyt?
>>
>>
>> On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>>
>>
>>
>> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych
<corinnekrych(a)gmail.com>wrote:
>>
>> in selective push is:
>> ==> variant: iOS + alias: mwessendorf
>> a valid criteria too?
>>
>>
>>
>> yes. let me update the related doc(s)
>>
>>
>>
>>
>> On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>>
>>
>>
>>
>> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>
>> TYPO:
>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
>> deviceType:iPadMini + alias: mwessendorf
>> or
>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
>> deviceType:iPhone + alias: mwessendorf
>>
>>
>>
>>
>>
>> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf
<matzew(a)apache.org>wrote:
>>
>>
>>
>>
>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych
<corinnekrych(a)gmail.com>wrote:
>>
>> When doing selective push query, is there any overlap between mobile
>> variant (which I understand like mobile type which contains certificates)
>> and device type?
>>
>>
>> MobileVariant (or call it type) is something like "Android", or
"iOS".
>> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android
>> Table", "Andrpid phone", android what not
>>
>>
>> Sure.... ideally there are several variants:
>> - iOS iPhone 5 optimised app in the app store
>> - iOS iPhone 4s optimised app in the app store
>> - iOS iPhone 3 optimised app in the app store
>> - iOS iPad mini optimised app in the app store
>> etc :)
>>
>> But, if there is only one variant, it's totally valid to install an iOS
>> application (from the appstore), on an iPad and an iPhone;
>>
>>
>> Both aimed at defining categories.
>> Are those categories defined and fixed in the spec or can they be
>> extended?
>>
>>
>>
>> I don't understand categories, here
>>
>>
>> Can we do a selective push based on mobileType=mobile variant and
>> alias=john@gmail?
>>
>>
>>
>
> --
> 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
3:19 p.m.
Boo YA
On Jun 4, 2013, at 9:17 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Luke
once this landed, it will be "pushApplicationID" and "variantID" -
the ID is than meaningless (at least for PushEE server).
-M
On Fri, May 31, 2013 at 6:45 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
plus plus
On May 31, 2013, at 12:39 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
> https://issues.jboss.org/browse/AGPUSH-86
>
>
> On Fri, May 31, 2013 at 6:25 PM, Luke Holmquist <lholmqui(a)redhat.com> wrote:
>
>
> Sent from my iPhone
>
> On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>> somehow the device needs to say: "I belong to android variant"
>>
>> besides the @Id /PK, we can have a second field / column that represents:
>> * PushAppID
>> * VariantID
>>
>
> Yup. Having these would solve that
>
>
>>
>> Was that your question?
>>
>> On Friday, May 31, 2013, Lucas Holmquist wrote:
>> something that i was thinking about after doing some examples is that i'm not
sure how i feel about using the PK's of each table as the identifier to
register/broadcast clients.
>>
>> We are sort of giving meaning to data that really shouldn't have meaning. it
should really only be used to identify the row. It might be better to have another key on
each table/object that is the identifier.
>>
>> So in one of the examples i did, the app on the device will register the device
with the push server, but i needed to also include the id of the variant instance
>>
>> i guess i'm thinking if someone migrates their database, these keys could
get messed up.
>>
>>
>> wdyt?
>>
>>
>> On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
>>> in selective push is:
>>> ==> variant: iOS + alias: mwessendorf
>>> a valid criteria too?
>>>
>>>
>>> yes. let me update the related doc(s)
>>>
>>>
>>>
>>> On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>>>
>>>
>>>
>>> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>> TYPO:
>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPadMini + alias: mwessendorf
>>> or
>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
deviceType:iPhone + alias: mwessendorf
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf
<matzew(a)apache.org> wrote:
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych
<corinnekrych(a)gmail.com> wrote:
>>> When doing selective push query, is there any overlap between mobile variant
(which I understand like mobile type which contains certificates) and device type?
>>>
>>> MobileVariant (or call it type) is something like "Android", or
"iOS".
>>> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android
Table", "Andrpid phone", android what not
>>>
>>>
>>> Sure.... ideally there are several variants:
>>> - iOS iPhone 5 optimised app in the app store
>>> - iOS iPhone 4s optimised app in the app store
>>> - iOS iPhone 3 optimised app in the app store
>>> - iOS iPad mini optimised app in the app store
>>> etc :)
>>>
>>> But, if there is only one variant, it's totally valid to install an iOS
application (from the appstore), on an iPad and an iPhone;
>>>
>>> Both aimed at defining categories.
>>> Are those categories defined and fixed in the spec or can they be extended?
>>>
>>>
>>> I don't understand categories, here
>>>
>>> Can we do a selective push based on mobileType=mobile variant and
alias=john@gmail?
>>>
>>
>>
>> --
>> 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
8:07 a.m.
Landet on master
On Tue, Jun 4, 2013 at 3:19 PM, Lucas Holmquist <lholmqui(a)redhat.com> wrote:
Boo YA
On Jun 4, 2013, at 9:17 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Luke
once this landed, it will be "pushApplicationID" and "variantID" -
the ID
is than meaningless (at least for PushEE server).
-M
On Fri, May 31, 2013 at 6:45 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
> plus plus
>
> On May 31, 2013, at 12:39 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
> https://issues.jboss.org/browse/AGPUSH-86
>
>
> On Fri, May 31, 2013 at 6:25 PM, Luke Holmquist <lholmqui(a)redhat.com>wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>> somehow the device needs to say: "I belong to android variant"
>>
>> besides the @Id /PK, we can have a second field / column that represents:
>> * PushAppID
>> * VariantID
>>
>> Yup. Having these would solve that
>>
>>
>>
>> Was that your question?
>>
>> On Friday, May 31, 2013, Lucas Holmquist wrote:
>>
>>> something that i was thinking about after doing some examples is that
>>> i'm not sure how i feel about using the PK's of each table as the
>>> identifier to register/broadcast clients.
>>>
>>> We are sort of giving meaning to data that really shouldn't have
>>> meaning. it should really only be used to identify the row. It might be
>>> better to have another key on each table/object that is the identifier.
>>>
>>> So in one of the examples i did, the app on the device will register
>>> the device with the push server, but i needed to also include the id of
>>> the variant instance
>>>
>>> i guess i'm thinking if someone migrates their database, these keys
>>> could get messed up.
>>>
>>>
>>> wdyt?
>>>
>>>
>>> On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych
<corinnekrych(a)gmail.com>wrote:
>>>
>>> in selective push is:
>>> ==> variant: iOS + alias: mwessendorf
>>> a valid criteria too?
>>>
>>>
>>>
>>> yes. let me update the related doc(s)
>>>
>>>
>>>
>>>
>>> On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>>>
>>>
>>>
>>>
>>> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>>
>>> TYPO:
>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
>>> deviceType:iPadMini + alias: mwessendorf
>>> or
>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
>>> deviceType:iPhone + alias: mwessendorf
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <matzew(a)apache.org
>>> > wrote:
>>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com
>>> > wrote:
>>>
>>> When doing selective push query, is there any overlap between mobile
>>> variant (which I understand like mobile type which contains certificates)
>>> and device type?
>>>
>>>
>>> MobileVariant (or call it type) is something like "Android", or
"iOS".
>>> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android
>>> Table", "Andrpid phone", android what not
>>>
>>>
>>> Sure.... ideally there are several variants:
>>> - iOS iPhone 5 optimised app in the app store
>>> - iOS iPhone 4s optimised app in the app store
>>> - iOS iPhone 3 optimised app in the app store
>>> - iOS iPad mini optimised app in the app store
>>> etc :)
>>>
>>> But, if there is only one variant, it's totally valid to install an iOS
>>> application (from the appstore), on an iPad and an iPhone;
>>>
>>>
>>> Both aimed at defining categories.
>>> Are those categories defined and fixed in the spec or can they be
>>> extended?
>>>
>>>
>>>
>>> I don't understand categories, here
>>>
>>>
>>> Can we do a selective push based on mobileType=mobile variant and
>>> alias=john@gmail?
>>>
>>>
>>>
>>
>> --
>> 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
5:36 p.m.
reminder, that ID is just the primary key :-)
meaningful are "pushApplicationID" and "variantID"
On Tue, Jun 4, 2013 at 3:17 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
Luke
once this landed, it will be "pushApplicationID" and "variantID" -
the ID
is than meaningless (at least for PushEE server).
-M
On Fri, May 31, 2013 at 6:45 PM, Lucas Holmquist <lholmqui(a)redhat.com>wrote:
> plus plus
>
> On May 31, 2013, at 12:39 PM, Matthias Wessendorf <matzew(a)apache.org>
> wrote:
>
> https://issues.jboss.org/browse/AGPUSH-86
>
>
> On Fri, May 31, 2013 at 6:25 PM, Luke Holmquist <lholmqui(a)redhat.com>wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On May 31, 2013, at 12:24 PM, Matthias Wessendorf <matzew(a)apache.org>
>> wrote:
>>
>> somehow the device needs to say: "I belong to android variant"
>>
>> besides the @Id /PK, we can have a second field / column that represents:
>> * PushAppID
>> * VariantID
>>
>> Yup. Having these would solve that
>>
>>
>>
>> Was that your question?
>>
>> On Friday, May 31, 2013, Lucas Holmquist wrote:
>>
>>> something that i was thinking about after doing some examples is that
>>> i'm not sure how i feel about using the PK's of each table as the
>>> identifier to register/broadcast clients.
>>>
>>> We are sort of giving meaning to data that really shouldn't have
>>> meaning. it should really only be used to identify the row. It might be
>>> better to have another key on each table/object that is the identifier.
>>>
>>> So in one of the examples i did, the app on the device will register
>>> the device with the push server, but i needed to also include the id of
>>> the variant instance
>>>
>>> i guess i'm thinking if someone migrates their database, these keys
>>> could get messed up.
>>>
>>>
>>> wdyt?
>>>
>>>
>>> On May 28, 2013, at 2:53 AM, Matthias Wessendorf <matzew(a)apache.org>
>>> wrote:
>>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 8:51 AM, Corinne Krych
<corinnekrych(a)gmail.com>wrote:
>>>
>>> in selective push is:
>>> ==> variant: iOS + alias: mwessendorf
>>> a valid criteria too?
>>>
>>>
>>>
>>> yes. let me update the related doc(s)
>>>
>>>
>>>
>>>
>>> On 28 May 2013 08:51, Corinne Krych <corinnekrych(a)gmail.com> wrote:
>>>
>>>
>>>
>>>
>>> On 28 May 2013 08:48, Matthias Wessendorf <matzew(a)apache.org> wrote:
>>>
>>> TYPO:
>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
>>> deviceType:iPadMini + alias: mwessendorf
>>> or
>>> ==> variant: iOS (since a PushAPP _might_ have only one iOS variant) +
>>> deviceType:iPhone + alias: mwessendorf
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 8:43 AM, Matthias Wessendorf <matzew(a)apache.org
>>> > wrote:
>>>
>>>
>>>
>>>
>>> On Tue, May 28, 2013 at 12:00 AM, Corinne Krych <corinnekrych(a)gmail.com
>>> > wrote:
>>>
>>> When doing selective push query, is there any overlap between mobile
>>> variant (which I understand like mobile type which contains certificates)
>>> and device type?
>>>
>>>
>>> MobileVariant (or call it type) is something like "Android", or
"iOS".
>>> deviceTypes would be iPad, iPod, iPhone, iWatch :) - or "Android
>>> Table", "Andrpid phone", android what not
>>>
>>>
>>> Sure.... ideally there are several variants:
>>> - iOS iPhone 5 optimised app in the app store
>>> - iOS iPhone 4s optimised app in the app store
>>> - iOS iPhone 3 optimised app in the app store
>>> - iOS iPad mini optimised app in the app store
>>> etc :)
>>>
>>> But, if there is only one variant, it's totally valid to install an iOS
>>> application (from the appstore), on an iPad and an iPhone;
>>>
>>>
>>> Both aimed at defining categories.
>>> Are those categories defined and fixed in the spec or can they be
>>> extended?
>>>
>>>
>>>
>>> I don't understand categories, here
>>>
>>>
>>> Can we do a selective push based on mobileType=mobile variant and
>>> alias=john@gmail?
>>>
>>>
>>>
>>
>> --
>> 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
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
3963
days inactive
3980
days old
23 comments
10 participants
participants (10)
-
Corinne Krych -
Daniel Bevenius -
Daniel Passos -
Douglas Campos -
Kris Borchers -
Lucas Holmquist -
Luke Holmquist
-
Matthias Wessendorf -
Sebastien Blanc -
Sébastien Blanc