I have a client/server app in which the client sends objects in the form of JSON to the server which runs a PHP script and then places this data into a database.
The problem is that decoding is done with the json_decode function which seems to work on strings not streams. Is there a way to take the inpustream from the HTTP request and use a streaming JSON parser to reduce the memory foot print.
I come from a java background where there are a couple of frameworks like jackson , xtream for this. Is there a PHP equivalent? Otherwise it seems I'll run into scalability issues.
I wrote a little pure PHP JSON streaming parser that works on streams. Hope that it's the kind of thing you're looking for.
You may want to try parse yourself the php://input stream (with fopen()) but IMHO every SAPI (apache-mod-php, fastcgi) are waiting the end of the HTTP request before sending it to php so it won't be useful.
Related
So I am new to Perl and web development but I was hoping to get some guidance on the following issue.
Server 1 is transcoding video for me and has an api endpoint for me to access. It will give me the file stream that I want to push to the web.
So for the sake of the problem lets say that it is accessed at:
server1:123\video_stream
Server2 is my web server and I want to have a page that lets us access this video stream file
server2:80\web_stream
I have seen in php you can do readfile("server1:123\video_stream) but the entire video_stream will be read into memory before being output to the page... or so I was told.
I have also seen in Perl that ffmpeg output can but routed through the open(DATA, $ffmpegProcess) then printing the buffer read from this stream to the web_stream page...
This all assumes that the header information about the attributes of the video are correct.
Would it be as simple as making a curl request to Server 1 and returning that stream output like I can already with the ffmpeg output?
I am not looking for complete solution, just some direction on the best and most correct way to do this. Maybe php and Perl are not the right tools to handle this at all?
ffserver seems like the better tool to use. It's part of the ffmpeg family.
PHP readfile() is a good way to do this. If you read the PHP manual page the discussion tells you how to deal with different possibilites of reading the file in chunks and dealing with memory issues.
I was landed a project to debug a PHP SOAP server (SoapServer) written by an unknown party. It is being used by a c# SOAP client, which I don't have access to the source code to (in other words, I cannot use __getLastResponse to see what it gets). I am trying to capture XML output of the server's responses. Traffic sniffing (wireshark, etc) doesn't work because of the SSL layer being used to encrypt XML messages. Any help in figuring out how to see the XML messages sent out by the server would be greatly appreciated.
There's an excellent example for extending the SoapServer class and grabbing the Soap XML request and responses here: http://blog.mayflower.de/archives/179-Extending-class-SoapServer-PHP5-for-debugging.html
Does the SoapServer look like this one, or like this one? If it's the former, you're up a tree and every ladder within a year's distance has been violently destroyed by wolverines. Rather, it's a binary blob of compiled code from which there is no escape.
If it's the latter, you may have some hope -- the service method's third parameter can be set to true to get the response data rather than blindly sending it out.
There's also a rumor that the ancient "nuSOAP" library has a server mode, but that project seems to have imploded in upon itself, and took the documentation with it.
Long-term, you may be better served by using a web service layer that isn't pathologically backwards, though that might not be an option for you.
I am actually looking for some opinion on how to get this done. I have a php server with a mysql backend to authenticate users using android os. I came across the debate of having JSON vs XML to minimize the overhead and using REST vs SOAP. Can I get some tips on what is the best path to go about getting this done ? I know its a trade-off if I use JSON/REST because its a bit complicated than XML/SOAP
JSON/REST is simpler than XML/SOAP. It has less overhead since you don't need the extra SOAP portions of the message. Also Android has JSON parseing APIs.
does GWT support php ?
Useful links:
http://www.ibm.com/developerworks/xml/library/x-gwtphp/ (07 Apr 2009 )
and
http://www.gwtphp.com/
http://sourceforge.net/projects/gwtphp/)
http://code.google.com/p/gwtphp/
Havent used, so I can't tell if it's any good
To a certain extent, yes.
The heart of GWT is some magic for converting Java source code for a Web client into JavaScript. There's no wiggle room there; it's either Java or nothing.
But a GWT-translated client can interoperate with a server written in any language. You'd be missing out on some of the special remote calling capabilities offered by the GWT framework, but if you're willing to transfer XML or JSON back and forth, a PHP-based server could work with your Java/JavaScript-based client.
Yes, GWT completely supports PHP. Write your PHP script and use request builder to make the ajax call, then make your PHP return JSON data and use JSON parser within GWT to parse your JSON.
Normally, when you create a GWT application, it runs with the default java server, to direct it to your php server, use the following,
noserver -remoteUI "${gwt_remote_ui_server_port}:${unique_id}"
-startupUrl <name>.html
-logLevel INFO -codeServerPort 9997
-war /opt/lampp/htdocs/../war com.<appname>.<appname>
if ever you are using eclipse, simply place the app on your php server you are using
I want to have a PHP script send a XML formatted string to another PHP script that resides on a different server in a different part of town.
Is there any nice, clean way of doing this?
(PHP5 and all the latest software available)
check out cURL for posting data between pages.
If it were me, I would just POST the xml data to the other script. You could use a socket from PHP, or use CURL. I think that's the cleanest solution, although SOAP is also viable if you don't mind the overhead of the SOAP request, as well as using a library.
I strongly suggest rolling your own RESTful API and avoiding the complexity of SOAP altogether. All you need is the curl extension to handle the HTTP request/response, and simple_xml to build/process the XML. If your data is in a reasonable format, it should be easy for you to push it into an XML string and submit it as a POST to the other server. That server will respond to the request by reading the XML string from the POST var back into an object, and voila! It shouldn't take you all day to whip this out.
XML-RPC or SOAP or just a RESTful API
You can use cURL (complex API), the http extension (cleaner), or if you need to do more complex stuff you can even use the Scriptable Browser from simpletest.