C-B4 changes to Aerogear

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

C-B4 changes to Aerogear

yaniv-cb4
Hi all, During the last 4-5 months C-B4 had made some changes to AeroGear server.
I would like do discuss those changes with you guys in order to decide which are relevant for aerogear upstream.

Technical issues,
1) Maven changes to support Wildfly 8.2.1.
2) Maven eclipse integration, include js resources into output war.
3) unifiedpush-service - use arquillian/wildfly instead of openejb.
4) unifiedpush-jaxrs - additional tests using arquillian.

Feature changes:
1) Documents API - Store & Forward documents. Designed to support large payload, store json doc and send silent push.
2) Register installation in disabled mode. First step to versification process.
3) Enable device based on verification process (SMS/Email). Plugable architecture. default impl uses Clickatell API but can be configures to any other vendor impl.
4) Extended Multitenancy - Link aliases to application. First step to section 5  
5) Move installation to new variant/application based on alias relation.
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] C-B4 changes to Aerogear

Matthias Wessendorf
Hi Yaniv!

thanks for reaching out!

On Tue, Mar 15, 2016 at 8:22 AM, yaniv-cb4 <[hidden email]> wrote:
Hi all, During the last 4-5 months C-B4 had made some  changes
<https://github.com/C-B4/unifiedpush-server/>   to AeroGear server.
I would like do discuss those changes with you guys in order to decide which
are relevant for aerogear upstream.

Technical issues,
1) Maven changes to support Wildfly 8.2.1.
2) Maven eclipse integration, include js resources into output war.
3) unifiedpush-service - use arquillian/wildfly instead of openejb.
4) unifiedpush-jaxrs - additional tests using arquillian.

as indicated on our GH commit thread ([1]) over the last days, I am happy to get all of these into our master branch :)

 

Feature changes:
1) Documents API - Store & Forward documents. Designed to support large
payload, store json doc and send silent push.

Sounds nice! This means a new/different sender API was added for sending large payload (too large for iOS (e.g. bigger than 2k))?
The payload is stored on the UPS DB and can be fetched by the devices (e.g. after a silent push) via HTTP basic? Or are these "fetch" routes Keycloak protected?


 
2) Register installation in disabled mode. First step to versification
process.
3) Enable device based on verification process (SMS/Email). Plugable
architecture. default impl uses Clickatell API but can be configures to any
other vendor impl.

Ah, this is nice feature as well. By default (or per setting), all devices are initially disabled for push, right? Via successful SMS/EMail verification the push will be enabled for the device?

I do like this and can see interest in this at our community. Glad to see the architecture is plugable, because I am not too thrilled about hard-coded dependencies against some proprietary SMS API. How can the actual SMS (or Email) implementation be enabled/configured?

 
4) Extended Multitenancy - Link aliases to application. First step to
section 5
5) Move installation to new variant/application based on alias relation.


Can you explain a bit more on this e.g. what's the use-case here ? 

Thanks again for reaching out!


Cheers,
Matthias





 

--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/C-B4-changes-to-Aerogear-tp12395.html
Sent from the aerogear-dev mailing list archive at Nabble.com.
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

Re: [aerogear-dev] C-B4 changes to Aerogear

Matthias Wessendorf
Hi Yaniv

On Tue, Mar 15, 2016 at 8:39 AM, Matthias Wessendorf <[hidden email]> wrote:
Hi Yaniv!

thanks for reaching out!

On Tue, Mar 15, 2016 at 8:22 AM, yaniv-cb4 <[hidden email]> wrote:
Hi all, During the last 4-5 months C-B4 had made some  changes
<https://github.com/C-B4/unifiedpush-server/>   to AeroGear server.
I would like do discuss those changes with you guys in order to decide which
are relevant for aerogear upstream.

Technical issues,
1) Maven changes to support Wildfly 8.2.1.
2) Maven eclipse integration, include js resources into output war.
3) unifiedpush-service - use arquillian/wildfly instead of openejb.
4) unifiedpush-jaxrs - additional tests using arquillian.

as indicated on our GH commit thread ([1]) over the last days, I am happy to get all of these into our master branch :)

wondering if there is still interest in contributing some of this back. I think we could get 1 -> 4 on the 1.1.x branch.
While master is on WF-10, I think only 2 -> 4 make sense there.

Any thoughts ? 
 

 

Feature changes:
1) Documents API - Store & Forward documents. Designed to support large
payload, store json doc and send silent push.

Sounds nice! This means a new/different sender API was added for sending large payload (too large for iOS (e.g. bigger than 2k))?
The payload is stored on the UPS DB and can be fetched by the devices (e.g. after a silent push) via HTTP basic? Or are these "fetch" routes Keycloak protected?


 
2) Register installation in disabled mode. First step to versification
process.
3) Enable device based on verification process (SMS/Email). Plugable
architecture. default impl uses Clickatell API but can be configures to any
other vendor impl.

Ah, this is nice feature as well. By default (or per setting), all devices are initially disabled for push, right? Via successful SMS/EMail verification the push will be enabled for the device?

I do like this and can see interest in this at our community. Glad to see the architecture is plugable, because I am not too thrilled about hard-coded dependencies against some proprietary SMS API. How can the actual SMS (or Email) implementation be enabled/configured?

 
4) Extended Multitenancy - Link aliases to application. First step to
section 5
5) Move installation to new variant/application based on alias relation.


Can you explain a bit more on this e.g. what's the use-case here ? 

Thanks again for reaching out!


Cheers,
Matthias





 

--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/C-B4-changes-to-Aerogear-tp12395.html
Sent from the aerogear-dev mailing list archive at Nabble.com.
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



--



--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev