Are these steps similar to what those (unfinished/untested) functions in ptp.c (in the v2 patch) are supposed to do? (ptp_chdk_rcinit, ptp_chdk_rcisready, ptp_chdk_rcgetname, ptp_chdk_rcgetfile)
Yes, that's what I had in mind. I still haven't had a chance to really look at it, but next weekend is looking good.
You mean setting file type(s), crop parameters independently of initing / uniniting the remote file target mode?
Yes.
I've been thinking about a use case where the camera runs a motion detection script, and the client fetches the pictures (continuously) as they become available. In this case the camera would stay in remote file target mode for a while. Maybe this could be considered.
Yes, it seems like this might be more convenient under script control. Question:
Should we allow both (could lead to odd situation if client uses both, also code complexity) or require that it be done in lua ? I'd be tempted to only do it in lua if we are going to allow lua at all, so PTP_CHDK_RemoteCaptureInit would be replaced by a lua function.
Since shooting requires sending lua anyway, it doesn't seem like this would be a big handicap. If anything would make the client simpler.
Thoughts ?
OK, but the return value of PTP_CHDK_RemoteCaptureIsReady will need to be placed somewhere (param2?)
We have quite a few params and bits free. I also realized after posting that this would make it no longer really "script" status

I wonder if it would make more sense to have this be a flag (remote capture chunk is available), and make PTP_CHDK_RemoteCaptureGetData just return the next chunk along with an ID of what it is ?
Also, for cameras with partial (RAW only) support, maybe the SDM method is the way to go (I haven't looked into that code, but I seem to recall that the RAW data is transferred over PTP and the JPEG - which is small - gets erased instantly). I think SDM fills the RAW buffer with some homogeneous value (0?) to achieve a really small JPEG.
I haven't looked at SDM, but if we go this way, it seems like it should be something you can set for script, could be useful in other situations beyond remote camera. e.g nuke_next_jpeg()
In some situations, keeping the all black jpeg could be useful, because it would still have the exif
Regarding development:
I understand you didn't want to use the trunk because it's moving too fast. What would you think about having this temporarily go in a branch of the current trunk ? I'd prefer to have it in svn somewhere to play with, and it's not going to go into the stable branch in the end.