Hi Adien, After reading more, I suggest you just do JSON over HTTP or similar.
I would not concern myself with http overhead... I clock 6000 (do-nothing) requests per second on localhost with mod_wsgi using ab. When valid alternatives exist that allow your innovative solution to use existing components, it is a very smart thing. Contact me off list with a little info about your server/os/python version and where to send this stuff. JG On Jul 3, 2011 11:06 AM, "aiden bell" <[email protected]> wrote: > > > On Jul 3, 3:12 am, Jason Garber <[email protected]> wrote: >> Before I went 100% python 3 and mod_wsgi, I wrote a number of apps with a >> php front end and python back end. >> >> In my case, after getting Advanced Programming in a Unix Environment, I >> wrote a pretty fast, multi process, multi application app server in python >> which accepted connections from php and made api calls to the proper python >> app. >> >> It also supported cross app api calls, so all apps used a common billing >> module, for example. >> >> The communication was done using Extruct, a library I wrote with >> similarities to protocol buffers, but not compiled. >> >> The code is yours if you want it. >> >> However, I eventually grew to realize that 100% python was superior, and >> went that way. We have some big important apps written on AppStruct >> framework and mod_wsgi and python 3. >> >> So I can really say "been there done that" and if you have a compelling >> reason to do it, I got the code. > Sounds interesting. I would be very interesting :) >> >> JG >> >> On Jul 2, 2011 3:50 PM, "aiden bell" <[email protected]> wrote: >> >> >> >> > Hi all, >> >> > I am designing a PHP frontend which uses business logic exclusively in >> > Python/mod_wsgi as a REST API. As both the PHP code and the API >> > endpoints will be hosted on the same machine (in this case, but not >> > for third-party developers) I want to cut as much HTTP overhead as >> > possible ... >> >> > My thinking was writing a PHP module in C which talks directly to the >> > mod_wsgi process in daemon mode. Possibly accepting a cURL context and >> > producing the same semantics as executing that. >> >> > Short of the above, thinking of going down the exec route on the >> > Python files themselves and mocking the WSGI environment ... but that >> > seems less clean to me. >> >> > I guess my question is: Any hints before I get digging through the >> > source? >> >> > Aiden >> >> > -- >> > You received this message because you are subscribed to the Google Groups >> "modwsgi" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> >> [email protected].> For more options, visit this group at >> >> http://groups.google.com/group/modwsgi?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups "modwsgi" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to [email protected]. > For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en. > -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
