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.

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.

On Mon, Jun 26, 2017 at 9:19 AM, Jose Miguel Gallas Olmedo < jgallaso(a)redhat.com&gt; 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

On Mon, Jun 26, 2017 at 9:19 AM, Jose Miguel Gallas Olmedo < jgallaso(a)redhat.com&gt; 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

Matthias is already unreachable but I think he agreed on this idea so I will proceed to send a PR with this changes.

I've created this ticket <https://issues.jboss.org/browse/AGPUSH-2127> so far and will work on the PR now. On 26 June 2017 at 11:02, Jose Miguel Gallas Olmedo <jgallaso(a)redhat.com&gt; wrote: > ​On 26 June 2017 at 10:19, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > >> >> >> On Mon, Jun 26, 2017 at 9:19 AM, Jose Miguel Gallas Olmedo < >> jgallaso(a)redhat.com&gt; 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(a)apache.org&gt; wrote: > >> >> >> On Mon, Jun 26, 2017 at 9:19 AM, Jose Miguel Gallas Olmedo < >> jgallaso(a)redhat.com&gt; 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(a)apache.org&gt; >>> wrote: >>> >>>> >>>> >>>> On Fri, Jun 23, 2017 at 4:08 PM, Jose Miguel Gallas Olmedo < >>>> jgallaso(a)redhat.com&gt; 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(a)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(a)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(a)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(a)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> > -- 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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev