Flask....

[Cosmat]

Dear author! Very much I ask you to give a hint how to implement your server code on a python on Flask. Most newbies on a python like me, master the server code exactly by means Flask. Please help). 'm sorry I'm from Russia and I do not speak English well. If he expressed his request as something bad. Excuse me)...

[waveform80]

Ahh ... there's actually a couple of good reasons I deliberately avoided Flask for this project, the second of which is rather important:

• The first was to keep the number of dependencies as low as possible (just to try and minimize the support requirements)

• The second was because, depending upon the environment in which the Flask application is deployed, it might work with the camera or might not. This is because the camera firmware strictly enforces the restriction that only one process may use the camera at a time (by "use" I mean simply initializing the camera is enough to be considered "using it"). Hence I wanted to avoid the scenario of people thinking they could happily deploy pistreaming under, say, Apache with mod_wsgi ("for performance"), it'd fire up a bunch of processes, all but one of which would immediately crash (in other words, me avoiding more support requirements :)

Basically, it is possible to make a Flask application that does the same thing as pistreaming: just break out the stuff in do_GET into various handlers. Not sure if Flask has anything specific for websockets - so you might want to keep ws4py around or not, depending. However, what you have to be very careful about is that the application never forks (or spawns another copy of itself), and I'm not exactly certain where one would handle starting the recording and shutting down things (given Flask just returns a WSGI application, it's unclear where global init/cleanup goes - there's probably some simple answer though!).

You also have to be fairly careful that camera control is handled from the initializing thread (it is possible to do camera control from multiple threads, but you can easily deadlock if you do it from the recording thread which is implicitly started).

All in all, if I wanted to stick pistreaming into a larger web-application - I'd be more tempted to reverse proxy it from the existing script rather than deal with shoe-horning it into a framework which wants to do things that the camera firmware really won't like.