Hi Zack, My team at DVIDS is definitely interested. We will help with the project if you choose to open source it.
Thanks, Brian On Fri, Nov 18, 2016 at 6:14 PM, <[email protected]> wrote: > We've developed PHP server support in the form of a gRPC to FastCGI > (PHP-FPM) bridge. If there's interest, we'd definitely like to open source > it and get some more members of the community involved. > > Please feel free to reach out to me directly or through the mailing list: > [email protected]. > > On Friday, October 21, 2016 at 12:14:25 PM UTC+11, Gregg Donovan wrote: >> >> Thanks, Varun, much appreciated -- Etsy will dial in. >> >> On Thursday, October 20, 2016 at 1:53:47 PM UTC-4, Varun Talwar wrote: >>> >>> Team, we would like to understand problems and use cases for PHP server >>> in more depth and figure out a plan here. We would like to come up with a >>> reasonable solution which is not a one-off. We are happy to help and review >>> contribution in grpc-ecosystem <https://github.com/grpc-ecosystem> to >>> make this happen. I have added a meeting next week Thursday at 10:30 AM PDT >>> and included Greg, Brian, Ben, Stephen. If you want to get added to this >>> meeting or if the time doent't work for you, let me know. >>> >>> Thanks >>> >>> >>> >>> >>> On Tue, Oct 18, 2016 at 5:49 PM, Gregg Donovan <[email protected]> >>> wrote: >>> >>>> We (Etsy) are interested in server-side support for PHP in gRPC, as >>>> well. >>>> >>>> We have two main motivations that I imagine are relatively common. One, >>>> our PHP-based REST+JSON API >>>> <https://www.etsy.com/developers/documentation/getting_started/api_basics> >>>> has grown an internal pseudo-type system >>>> <https://codeascraft.com/2016/09/06/api-first-transformation-at-etsy-concurrency/> >>>> over the years that is beginning to look like protobuf or thrift and we'd >>>> rather just use a proper serialization format than evolve it. Two, we have >>>> API clients in Objective-C, Android, PHP, and JavaScript with homegrown >>>> code generation to make developing these clients easier. We see >>>> gRPC+Protobuf as a great possible solution to both issues. >>>> >>>> Nicolas -- I understand the reluctance to support PHP servers given >>>> that most folks are using PHP with Apache or nginix. But we would be >>>> thrilled to get started with unary RPC only. Perhaps, as PHP and >>>> Apache/nginix evolve their HTTP/2 support the gRPC PHP server support could >>>> evolve, as well. >>>> >>>> >>>> On Sunday, October 9, 2016 at 8:38:51 AM UTC-4, [email protected] >>>> wrote: >>>>> >>>>> >>>>> >>>>> On Thursday, April 21, 2016 at 7:24:35 AM UTC+2, Nicolas Noble wrote: >>>>>> >>>>>> The other languages (Ruby, Node.js, Python, C#, ...) don't have that >>>>>> issue, because they all have frameworks that are working properly from >>>>>> the >>>>>> command line. Right now, in order to run a gRPC python server, you can >>>>>> properly start a python daemon with your code in there. Node has >>>>>> everything >>>>>> built in for running servers without any front end. Ruby has been doing >>>>>> this natively as well for a long time. >>>>>> >>>>>> Unless somebody shows us otherwise, only PHP doesn't have any proper >>>>>> support to run a naked daemon. All the options that we've seen or that >>>>>> people have shown to us are toys or prototypes that aren't suitable for >>>>>> production usage. Basically, I'm challenging your "it is >>>>>> increasingly common to write standalone and daemonized PHP processes" and >>>>>> ask for proper examples and documentation that aren't flagged with >>>>>> warning >>>>>> labels such as "DO NOT USE FOR PRODUCTION". >>>>>> >>>>> >>>>> I think the right solution here could be to provide gRPC as a SAPI, >>>>> that means as a standalone binary "php-grpc server.php" much like >>>>> "php-fpm", it would start a HTTP/2 webserver and upon receiving the >>>>> requests, create individual PHP requests to server.php maybe with >>>>> appropriate context variables in $_SERVER/$_POST. This would keep the >>>>> sharded nothing PHP principle while allowing the C based gRPC server to >>>>> handle the long-livedness and streaming. But this might be to complex for >>>>> the benefit. >>>>> >>>>> A workaround could be to write a simple Go based proxy that accepts >>>>> requests over gRPC/HTTP2 and sends them out to a php-fpm based backend >>>>> using a Go fastcgi client library. >>>>> >>>>>> >>>>>> On Wed, Apr 20, 2016 at 7:55 PM, <[email protected]> wrote: >>>>>> >>>>>>> Nicholas, >>>>>>> >>>>>>> I'm also very interested in finding a way to make this work. I do >>>>>>> recognize the challenges you've outlined below as well as the fact that >>>>>>> the >>>>>>> PHP CLI server isn't suitable for production use. How do the other >>>>>>> language integrations for gRPC handle this? I would think that Python >>>>>>> would suffer from the same sort of issues with its SAPIs (mod_wsgi, >>>>>>> etc). >>>>>>> Or does gRPC only support naked Python processes as well? >>>>>>> >>>>>>> Looking at this example https://github.com/grp >>>>>>> c/grpc/blob/release-0_13/examples/python/route_guide/route_ >>>>>>> guide_server.py - PHP is capable of performing the same type of >>>>>>> socket listening operations going on under the hood here. It is >>>>>>> increasingly common to write standalone and daemonized PHP processes >>>>>>> like >>>>>>> this one. Whether or not PHP will natively support HTTP/2 features is >>>>>>> of >>>>>>> course another question. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> On Wednesday, January 27, 2016 at 9:14:54 PM UTC-5, Nicolas Noble >>>>>>> wrote: >>>>>>>> >>>>>>>> There are several problems with the idea of a gRPC server in PHP, >>>>>>>> and we have no plans for that. >>>>>>>> >>>>>>>> Basically, the only way it would work, is if you run PHP "naked", >>>>>>>> without its typical nginx or apache frontend. You can't serve a >>>>>>>> long-lived >>>>>>>> streaming RPC from a PHP page using typical settings. The page will >>>>>>>> timeout >>>>>>>> very quickly. You could theoretically restrict yourselves to server >>>>>>>> unary >>>>>>>> RPCs only, or have an arbitrary duration on "streaming" RPCs, but that >>>>>>>> wouldn't be "gRPC" anymore. And even then, there's no proper HTTP/2 >>>>>>>> support >>>>>>>> in PHP at the moment. With the typical model of having a frontend >>>>>>>> that'll >>>>>>>> forward the requests to PHP processes spawned on the fly, you wouldn't >>>>>>>> have >>>>>>>> access to the full HTTP/2 stream, which is required to properly server >>>>>>>> gRPC >>>>>>>> requests. >>>>>>>> >>>>>>>> For more on that, I invite you to research how to serve websockets >>>>>>>> from PHP. Probably all of the solutions you'll find will be by running >>>>>>>> a >>>>>>>> naked PHP process, without Apache. That isn't the typical way people >>>>>>>> want >>>>>>>> to use PHP. So a gRPC server in PHP would be fairly useless as it'd >>>>>>>> require >>>>>>>> you to run it in a very atypical deployment environment. >>>>>>>> >>>>>>>> On Wed, Jan 27, 2016 at 2:23 PM, <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hey all— >>>>>>>>> >>>>>>>>> It appears as of right now you can only create CLIENTS in PHP, but >>>>>>>>> not servers. I was wondering what the technical blockers behind this >>>>>>>>> were >>>>>>>>> and if it's on the roadmap for a future release? >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "grpc.io" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to [email protected]. >>>>>>>>> To post to this group, send email to [email protected]. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/d/msgid/grpc-io/412dccb6-836e-4486 >>>>>>>>> -ab19-34701bec0562%40googlegroups.com >>>>>>>>> <https://groups.google.com/d/msgid/grpc-io/412dccb6-836e-4486-ab19-34701bec0562%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "grpc.io" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> To post to this group, send email to [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/grpc-io/954a4480-dc8f-42c6 >>>>>>> -ab68-44d884634e37%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/grpc-io/954a4480-dc8f-42c6-ab68-44d884634e37%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "grpc.io" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at https://groups.google.com/group/grpc-io. >>>> To view this discussion on the web visit https://groups.google.com/d/ms >>>> gid/grpc-io/bbf2d3a8-a456-46cb-bcac-7966e4d4cf40%40googlegroups.com >>>> <https://groups.google.com/d/msgid/grpc-io/bbf2d3a8-a456-46cb-bcac-7966e4d4cf40%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> >>> >>> -- >>> Varun Talwar | Product Manager | [email protected] | 415-341-7352 >>> >>> >>> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2BK14zEBe2eH7vdXb32agXPjCE2hDLxaPAFc57ZcDCU9qe3F2Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
