[aerogear-dev] Refactoring push-network-proxies
Jose Miguel Gallas Olmedo
jgallaso at redhat.com
Mon Jun 26 05:02:31 EDT 2017
On 26 June 2017 at 10:19, Matthias Wessendorf <matzew at apache.org> wrote:
>
>
> On Mon, Jun 26, 2017 at 9:19 AM, Jose Miguel Gallas Olmedo <
> jgallaso at redhat.com> wrote:
>
>>
>> not sure if we should delete it yet - I think it was written by QE to
>>> test GCMv2 - but push server is now GCMv3/FCM compliant. I think there is
>>> some features missing there. Perhaps it's still good - not really sure.
>>
>>
>> Actually, we could keep the old gcm-proxy as well. The repo is
>> "push-network-proxies" which means many proxies. We could store the new one
>> under "fcm-wiremock" and the old one under "gcm-java"
>>
>
> +1
>
>
>> but for this, I think, we ought to extract GCM logic from the current
>> project, leaving only APNS stuff.
>>
>
> no, not just APNs, IMO
>
I think I didn't explain it clear enough, let me start again: The current
repository is a java project that implements both GCM and APNS proxies.
What I mean with "extract GCM logic from the project" is exactly what you
see in the structure: "apns-java" would have the original
"push-network-proxies" java project but only with the APNS implementation
and "gcm-java" would have the original "push-network-proxies" java project
but only with GCM implementation. Maybe "decouple" would be a better term.
Does it make more sense now or didn't I understand you point maybe?
--
JOSE MIGUEL GALLAS OLMEDO
ASSOCIATE QE, mobile
Red Hat
<https://www.redhat.com/>
M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
On 26 June 2017 at 10:19, Matthias Wessendorf <matzew at apache.org> wrote:
>
>
> On Mon, Jun 26, 2017 at 9:19 AM, Jose Miguel Gallas Olmedo <
> jgallaso at redhat.com> wrote:
>
>>
>> not sure if we should delete it yet - I think it was written by QE to
>>> test GCMv2 - but push server is now GCMv3/FCM compliant. I think there is
>>> some features missing there. Perhaps it's still good - not really sure.
>>
>>
>> Actually, we could keep the old gcm-proxy as well. The repo is
>> "push-network-proxies" which means many proxies. We could store the new one
>> under "fcm-wiremock" and the old one under "gcm-java"
>>
>
> +1
>
>
>> but for this, I think, we ought to extract GCM logic from the current
>> project, leaving only APNS stuff.
>>
>
> no, not just APNs, IMO
>
>>
>> push-network-proxies/
>> fcm-wiremock/
>> ...
>> apns-java/
>> ...
>> gcm-java/
>> ...
>> push-network-proxies-template.yml
>>
>
> I think this is a good structure
>
>
>>
>> In the future we might want to add new different implementations (or new
>> proxies) so it makes sense to me to have push-network-proxies as an
>> extensible repository, not as a only-2-proxies one.
>>
>> On 24 June 2017 at 15:33, Matthias Wessendorf <matzew at apache.org> wrote:
>>
>>>
>>>
>>> On Fri, Jun 23, 2017 at 4:08 PM, Jose Miguel Gallas Olmedo <
>>> jgallaso at redhat.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I recently create a Docker image of our push FCM proxy, made with
>>>> Wiremock. Since we are no longer using the FCM proxy in
>>>> https://github.com/aerogear/push-network-proxies (even the Dockerfile
>>>> there only consider APNs) I think we could remove it from there and
>>>> refactor the repository like this:
>>>>
>>>
>>> not sure if we should delete it yet - I think it was written by QE to
>>> test GCMv2 - but push server is now GCMv3/FCM compliant. I think there is
>>> some features missing there. Perhaps it's still good - not really sure.
>>>
>>> But if Wiremock offers what we need -> fine, better to use things that
>>> are supported through a larger community ;-)
>>>
>>>
>>>>
>>>> push-network-proxies/
>>>> fcm/
>>>> Dockerfile
>>>> ...
>>>> apns/
>>>> Dockerfile
>>>> ...
>>>> push-network-proxies-template.yml
>>>>
>>>> So that we have everything in the same place. I also made a template
>>>> for Openshift so that we can setup a testing environment for UPS quickly. I
>>>> think that's the ultimate point of having the mocks together.
>>>>
>>>
>>> I like that, having this structure, where FCM is based on Wiremock,
>>> right?
>>>
>>>
>>>>
>>>> WDYT?
>>>>
>>>> --
>>>>
>>>> JOSE MIGUEL GALLAS OLMEDO
>>>>
>>>> ASSOCIATE QE, mobile
>>>>
>>>> Red Hat
>>>>
>>>> <https://www.redhat.com/>
>>>>
>>>> M: +34618488633
>>>> <http://redhatemailsignature-marketing.itos.redhat.com/>
>>>> <https://red.ht/sig>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>>
>>>
>>> --
>>> Matthias Wessendorf
>>>
>>> blog: http://matthiaswessendorf.wordpress.com/
>>> twitter: http://twitter.com/mwessendorf
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>>
>> JOSE MIGUEL GALLAS OLMEDO
>>
>> ASSOCIATE QE, mobile
>>
>> Red Hat
>>
>> <https://www.redhat.com/>
>>
>> M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
>>
>> <https://red.ht/sig>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> twitter: http://twitter.com/mwessendorf
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
JOSE MIGUEL GALLAS OLMEDO
ASSOCIATE QE, mobile
Red Hat
<https://www.redhat.com/>
M: +34618488633 <http://redhatemailsignature-marketing.itos.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20170626/71ab7516/attachment-0001.html
More information about the aerogear-dev
mailing list