[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