OAuth2 Adapter
by Lucas Holmquist
We are planning on adding an OAuth2 adapter to the JS library for 1.3.0. We are going to code against the google OAuth2 playground stuff, but trying to follow the spec as much as possible and try to be as generic as we can.
I'm not sure if this should be an "adapter" or something different. If it is an adapter of the Authentication plugin( not sure what we are calling the different pieces. pipeline, data manager, etc.), then we should expect to see authentication methods( enroll, login, logout ), but i think this "adapter" should be much more than that.
It should be used to connect to secured services( api ) that a user allows, such as GCM for chrome or the google+ platform, or some other enterprisey thing.
I'm wondering if this should be a standalone thing. I kind of like this idea so when we do social login, which will most likely have OAuth2, we can just access it.
Thoughts?
11 years, 10 months
AGDROID-80 and unified Push
by Summers Pittman
So with GCM and Android, Google may decide to update the devices token.
The device will receive a Intent saying that the token has changed and
it needs to eventually update the remote server's data before the token
expires.
Right now the application checks the device id on startup and
reregisters if there is a change. If the user doesn't interact with the
applicaiton for a long period of time and the device token changes he
will eventually stop receiving messages.
Ideally, I would think that handling this as soon as the intent comes in
would be great. However, how should failures to reregister be handled?
My easy answer is Log and retry with exponential backoff (and maybe send
a error message).
WDYT?
12 years, 1 month
TODO app abandoning
by Christos Vasilakis
Hi team,
opening this thread to continue the discussion we had on our IRC meeting of whether we should abandon(or not) further development of our TODO app demo. There was a suggestion on the meeting to close any pending tickets regarding TODO and mark the app as 'Not maintained'.
My personal preference is to keep it till our 'showcase' eventually replaces it. This is related to our discussion on 'showcase' app ML threads here and here
Also, at least in iOS, for the feature set that the API utilises (Pipes, Store), the app is still up-to-date but I am not sure if that holds true for our other platforms too.
What do you think?
Thanks,
Christos
12 years, 1 month
Mozilla API Alignment for SimplePush
by Kris Borchers
As I work more and more toward aligning with the API spec laid out by Mozilla for SimplePush, I find myself needing to make a major change to the way we have implemented channel registrations. Basically what I have found is that our storage and reuse of channels between app restart/refresh, though meant to be an improvement to performance, is causing more issues than it's solving.
The Proposal
I would like to only persist the user agent id (UAID) in storage and only keep the channel registrations in memory while the app is running. Each time the app starts up, the workflow would be:
First Start
Client Hello => Server
Server Ack => Client
Client 1 or more channel registrations => Server
Server stores channel and sends pushEndpoint => Client
Client registers endpont => App Server or UP Server
Push messages abound
Restart / Refresh
Client Hello => Server
Server recognizes UAID and since no channels were included in Hello, all existing channels are removed as per the spec and sends Ack => Client
Client 1 or more channel registrations => Server
Server stores channel and sends pushEndpoint => Client
Client registers endpont => App Server or UP Server
Push messages abound
The only possible downside I see here is there will be slightly more chatter over the network since the registrations will happen every time the app loads. There should be no performance decrease and may see a performance boost since we will be eliminating a number of synchronous calls into localStorage. The main benefit is that this will allow us to almost completely synchronize our API with Mozilla's which would then allow for immediate use of one of our apps as a web app and Firefox OS app with NO modifications.
Any thoughts?
12 years, 2 months
[SimplePush] Subsystem configuration
by Daniel Bevenius
I've started on AGPUSH-242, which is about adding configuration options to
the SimplePush Server WildFly subsystem. I've created the following gist
with a suggestion:
https://gist.github.com/danbev/6294945
I'm still working on the config and not begun implementing yet.
Any comments or suggestions are welcome either here or as comments on the
gist itself.
Thanks,
/Dan
12 years, 2 months
Push: Server versions and roadmaps
by Matthias Wessendorf
Hi,
looking at the roadmaps on our homepage, I see the following three next
release cycles are:
* End October
* Mid January
* March 2014
Currently both 'push' servers are versioned as 0.8.0;
I am wondering about the next iterations. Would the next version be 0.9.0,
followed by 1.0.0 ?
Wondering if the January timeframe is the one where we want to really
release the bits as 1.0.0 ?
Or could we do: 0.9.0, 0.9.5 (or even 0.10) and a 1.0.0 in March ?
I think my personal perference would be:
* Oct -> 0.9.0
* Jan -> 0.9.5 (the cycle is short due to holidays etc)
* Mar -> 1.0.0 (what ever 1.0.0 means :-))
Any thoughts ?
-Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
12 years, 2 months
Why is not APNsPushNotificationSender @ApplicationScoped
by Stefan Miklosovic
Hi,
I am just proof-reading the whole aerogear-unifiedpush-server and I would like to know
why is not APNsPushNotificationSender @ApplicationScoped as other two senders in the same
package (org.jboss.aerogear.unifiedpush.message.sender), to be concrete:
GCMPushNotificationSender and SimplePushNotificationSender are both @ApplicationScoped
but the one regarding of iOS is not. Why?
Thanks!
Stefan Miklosovic
Red Hat Brno - JBoss QA WFK
e-mail: smikloso(a)redhat.com
irc: smikloso
12 years, 2 months
