[site] community page overhaul ?
by Matthias Wessendorf
Hi,
I realized that atm we don't link to our users list, a quick/urgent fix for
that is here:
https://github.com/aerogear/aerogear.org/pull/410
That perhaps not enough! On the 'community' link we basically include the
archive of the dev list.
What should we do with that community section? How about the following
Instead of including the archive (as part of the website), we can tweak the
'community' page a bit.
E.g. we list the different options we have for users to reach out:
** links to users/dev ML subscribe page
** links to users/dev ML archives
** info on IRC
** link to our github landing page
** info on our twitter account
I think the benefit of including this on a dedicated page, makes the info
also a bit more visible, instead of just having links to ML at the footer
of our website
What are your thoughts?
Greetings,
Matthias
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
10 years, 1 month
RELEASE: next try of aerogear-parent 0.2.9 release
by Matthias Wessendorf
Hi,
KC 1.0.4 hit maven central, and the version has been integrated in our
parent pom.
main reason for this release is in fact the new KC version.
The staging repo is here:
https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
Let me know about the release so we can get it out soon, to be on time for
our UPS release ;-)
Cheers,
Matthias
On Wed, Oct 29, 2014 at 1:27 PM, Matthias Wessendorf <matzew(a)apache.org>
wrote:
> Hi,
>
> I am canceling this release - we need to wait for 1.0.4.Final of Keycloak
>
>
> https://issues.jboss.org/browse/KEYCLOAK-797
>
>
>
>
>
> On Wed, Oct 29, 2014 at 9:39 AM, Andrea Vibelli <avibelli(a)redhat.com>
> wrote:
>
>> Hi Matt,
>> totally +1, go for it! :-)
>>
>> Thanks
>> Andrea
>>
>>
>> Matthias Wessendorf wrote
>> > Ahoy!
>> >
>> > I am proposing another release, mainly to pick up new keycloak version
>> > (1.0.3.Final), which contains several fixes.
>> >
>> > The staging repo is here:
>> >
>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_st...
>> >
>> > Let me know about the release so we can get it out soon, to be on time
>> for
>> > our UPS release ;-)
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>>
>> > aerogear-dev@.jboss
>>
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-RELEASE-aerogear-p...
>> Sent from the aerogear-dev mailing list archive at Nabble.com.
>> _______________________________________________
>> 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
10 years, 1 month
Large user base with Aerogear Unified Push
by michael
All,
We have been evaluating Aerogear Unified Push and things are going well so
far.
But up until now we have only had a small numbers of users (in the tens)
registering or requiring a push.
We are looking at adding push functionality into one of our core products.
Last time we did a major revision to our core product we had in the order of
half a million users upgrade to the new version in the first 24 hours.
Unfortunately I don't have stats to hand on the busiest hour during that
period.
If we add push to our Android and iOS versions of our application and a
large proportion of our users accept the new permission in app we could be
looking at hundreds of thousands of registrations in a day and tens of
thousands in an hour. Note that we are not migrating from another provider
so this will be a "cold start".
So my questions are:
- Has anyone used Aerogear at this sort of scale? (happy to talk out of band
if you don't want to put your name out in a forum)
- What is the best deployment architecture to go for in this case?
- Similar to the above question - will Aerogear work nicely behind a load
balancer?
- If there are multiple instances of the app running can it take advantage
of read slaves if DB is a bottle neck?
- Has anyone done any sizing or transaction rates against AWS instances?
- Do any of the database back ends perform better or worse for this sort of
on boarding?
Obviously once we get all of our users on we will want to push them some
messages. So has anyone done pushes to hundreds of thousands of users using
Aerogear? What was the approximate time from the start to the end of the
process?
Note I've read JIRA and haven't seen much related to scalability except
- https://issues.jboss.org/browse/AGPUSH-661 from
http://lists.jboss.org/pipermail/aerogear-dev/2014-May/007793.html
I also note with interest that dealing with pushing messages at scale isn't
without its challenges
-
http://stackoverflow.com/questions/16352131/apple-push-notifications-in-bulk
Any help greatly appreciated.
Regards,
Michael
PS - Assuming we do go with Aerogear we will happily write up our findings
on how it ended up ;)
--
View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Large-user-base-with-Aerogear-U...
Sent from the aerogear-dev mailing list archive at Nabble.com.
10 years, 1 month
Beyond SimplePush's simplicity
by Lukáš Fryč
Hey guys,
I'm working on a demo of UPS pushing to iOS, Android, Windows, as well as
Firefox OS using our Cordova plugin.
But as you know, with FFOS it is not that simple - since SimplePush
protocol allows to transfer just incremental versions, we are not able to
deliver any interesting message.
UnifiedPush Server could be a correct place where we unify and shield our
users from this limitation:
my idea is storing the message on UPS under the SimplePush endpoint URL.
Once the message with version reaches the client, he would contact UPS to
retrieve this message under a key ( pushEndpoint, version ).
The messages could have default built-in TTL to allow periodic cleanup.
What do you think?
Cheers,
~ Lukas
10 years, 1 month
SDKs for LiveOak
by Ken Finnigan
All,
For the next release we're looking to create some SDKs for iOS, Android,
JavaScript and a Cordova plugin for use with LiveOak.
Our preference is to build on top of what Aerogear has already developed,
or even simply use the AeroGear SDK's with a different set of connection
options??
As the AeroGear team are well versed in various issues of developing SDKs,
I was hoping to get some advice as to the best way for us to develop ours
such that they're only a very thin layer on top of AeroGear's SDKs.
Thanks in advance!
Ken
10 years, 1 month
