I would like to be able to stream multiple JSON entries over a single connection over time, I also need later to be able to send some RTSP or MJPEG data as well. Id like to not have to build a separate server on a separate port. What Id like to be able to do is get a reference to the underlying socket of the web request so that I can keep it open and stream out data whenever necessary.
I cant see any obvious way i can do this from the handleURL system. I could keep the session around by looping and sleeping the thread that is created and keep using the print command to send more data, but it doesnt look like that is going to work. Obviously headers and such are not added and sent until it knows the size of the data youre sending so I suspect this wont work at all. I suspect that nothing will be sent until I return true.
Is there anyway for me to override the normal HTML handling and manage it myself?
While that is true in the definition of the thing, its always been overtaken for various purposes.
For faster communications many browsers will allow that a connection be kept open for a time and re-used for more HTTP requests in order to avoid the overhead of starting up another TCP session and restarting a CGI or server instance of the backend.
WebSockets are started as an HTTP connection and then kept open for the async transfer of JSON objects or other resources. I think the web edition may use these itself for the main data connection between the interface and the back end. Im not sure though, they were buggy in earlier browser implementations and I recall that there were problems getting them to work properly across all browsers. I need to implement a web socket protocol for a 3rd party javascript interconnection system myself in this case and so I need to keep the socket around to push JSON objects down periodically and receive events from the javascript in this way.
MJPEG streams are done over mixed-replace mime types, other older push technology used this as well and its still supported by all the common browsers. You send the headers with a border defined and then the image data and the border. The browser will display what you send but keep the connection open. Then I can send another sent of HTTP headers and data and the border string again and the new image or whatever will replace the one currently on the server. This has been around forever and I would very much like to support this under certain circumstances too.
And beyond those officially valid reasons its sometimes very useful to be able to receive a connection of non-http data on the same port that youre already passing through the port. In another project I would like to be able to use a clients already available java applet. It needs to connect to the host and receive a simple stream of non-html data though it has valid http headers that connected to a regular cgi app in the original implementation. If I could receive that connection on the web port and then keep it open I would not have to implement an entirely different custom server with all the security and other overhead in time and effort and then explain to the client that actually they need to pass 2 ports through their firewire and maintain double the configuration and setup across the firewall and NAT system and whatnot. It would make sense to be able to do this I think.
So those are the specific reasons why I think this would be a rarely used, but very valuable when it is necessary ability to have
OK this is purely my opinion and if I’m wrong hopefully someone else will correct me…
While I understand what you are saying and have even done some of it in the past, I do not think it is in the scope of a XOJO web application. So far I see it as being a good solid way of delivering a web based database application with perhaps some lightweight services via the HandleURL method. Which I’m sure meets the needs of a large part of the community.
I looked before at using HandleURL to deliver an entire service application on it and concluded that while it might be possible, there were easier ways of doing it in other environments.
I was making a feature request, not trying to demean the fantasticness that is the web edition of xojo Giving me a reference to the socket should be a minimal amount of work. I need access to the class and a switch to turn off all the work they have already done in processing headers. thats all. Once done that will enable those of us who wish to deliver more complicated things than can be done in the interface the way it is the ability to do so. I realize this is a bit beyond the scope of what was imagined for the handleURL system. Reality however is always more complicated than the dreams of the IDE developers! I have to mix old and new. I have to make previous investments by companies continue to work today. I have to be able to do things that were not within the confines of the initial design. Thats not a problem with xojo. Xojo web edition is fantastic! Its just not 100% of everything that anyone could ever want. By giving me a little more access they enable me to use their product for more things. I want to leverage what I already can do with it by adding in a few other necessities. Im not asking for a webSocket implementation where they do all the work. Im not asking for an MJPEG implementation where they do all the work. Just give me access to the stream that is already there and Ill take care of the rest.
Got my vote!
In fact, I would love to have a “handleClientSocket” or “handleClientSocketForURL” thingy that would let me completely take over, and manually handle, the client socket of a web app and handle it just like any TCPsocket.
DataAvailable, SendProgress, SendComplete events, properties and methods etc.
Hi James and all,
I’m trying to implement speech recognition using Hound’s API. I think I need to stream a user’s microphone audio via an open HTTPS POST call, so it seems that I require the approach you’re proposing as well.
I have gotten webkitSpeechRecognition working, because the browser (Chrome) handles the stream connection for me. I’ve done some javascript bits using ExecuteJavascript(), but this will be out of my depth, for sure.
Can anyone confirm that what I need to do is essentially what James is asking about?
I was looking at Xojo Binarystream, but I can’t see how to connect the stream a user’s browser generates (in Javascript) back to the Xojo server. I was hoping this is possible with the existing Xojo feature set.
Youre building speech recognition into a website? I need to look into doing this too that would be awesome. The browser opens a CGI type connection to the server with the stream of data? And then something in the xojo app passes it off to the speech recognition stuff? Ill have to look up more to be sure but it does sound like a similar application. Can you pass the data into the recognizer as chunks? Or do you have to wait till you have an entire file and pass it in its entirety? If you can start the decoding before youve got the whole file then yes, getting access to the stream after the initial headers were parsed would let you do that.
From the Hound API docs: An HTTP POST request is used for spoken requests. The audio data is sent in the post body. The HTTP “chunked” encoding should be used for the audio. The audio must be in either Speex format for WAV format. Raw PCM audio samples aren’t accepted directly, though they can be sent in WAV format, which really just adds some header information and then uses raw PCM audio data.
Thinking about this, I wonder if this approach will slow things down. Maybe my success with webkitSpeechRecognition is due to the fact that the stream is directly from the client’s browser and not via my app’s server. I’m actually looking for something that is faster than google (i.e. webkitSpeechRecognition) but so far, webkitSpeechRecognition has the best accuracy of transcription (with my voice at least). The text of the transcribed audio is the only thing sent back to my server, which I’ve been able to accomplish using Xojo.triggerServerEvent() in the javacript.
