6:32 p.m.
On 2014-10-23, Matthias Wessendorf wrote:
On Wed, Oct 22, 2014 at 6:13 PM, Karel Piwko
<kpiwko(a)redhat.com> wrote:
> Hi All,
>
> I'd like to know your opinion on following changes to UnifiedPush
> Server. They are both focused on improving customization process for the
> cartridge.
>
> Just in short, current update process now:
> 1/ Clone official git repository of cartridge
> 2/ Extract wars and do the modifications or build ones
> 3/ Package wars
> 4/ Push cartridge to your own repository
> 5/ Create cartridge from your own repository
>
> Whereas, I'm proposing:
> 1/ Create cartridge from official repository
> 2/ Clone git repository for gear created by Openshift (by default if rhc
> is used)
> 3/ Modify some files there we expose for user modification
> 4/ Push back to make changes live
>
> What particular configuration elements I'm interested to have
> externalized?
>
> 1/ Ability to load keycloak.json from external location
>
> => This allows user to create cartridge and modify it prior the first
> access. This allows users to configure it to be consumable by other
> services automatically, e.g. they can add developer users, roles, etc.
>
hrm, in theory, yeah, that could be possible. Perhaps Stian or abstractj
have an idea here
Everything is possible with software, the question is: do we really need
this? How would you feel if keycloak.json was changed by the wrong
person?
Can we as a project guarantee the security of this file outside the
server?
>
> 2/ Externalize GCM/APNs locations
>
> => Now, URLs are hardcoded in GCM/APNs JARs.
yes, they are considered stable APIs :)
We are not going to 'externalize' these URLs
> If they would be loaded
> from external location (defaults can still be hardcoded), this allows
> user to easily check business logic that queries data in UPS and not
> sending any messages. Also allows to put proxy in between UPS and
> APNs/GCMs.
>
> Both these will significantly reduce QE overhead. However, I believe
> they are valuable for other as well.
>
> Feedback and tomatoes (I prefer plum ones) are welcomed.
>
> Thanks,
>
> Karel
>
> _______________________________________________
> 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
--
abstractj
PGP: 0x84DC9914