First, thanks for doing this work, and responding to my initial, flamey reaction.
It seems your main point is about adding functionality to Lua vs. adding it to CHDK PTP. At least, most of the big things you question seem to be a consequence of this choice.
Agreed.
I think the rationale has been given in the past, but it comes down to me having preferred a minimal CHDK PTP. And a large argument for that is that adding more to it makes incompatible protocol revisions more likely. The new functionality is not a part of CHDK PTP, just something that is used through it.
That seems like a marginal distinction. It is effectively part of the CHDK PTP protocol. To actually get the live view data, any client has to accept a data phase from PTP_CHDK_CallFunction, and then understand the results. Realistically, this is one of the main features people will want PTP for, so it makes sense to have the method of doing that be a first class part of the protocol.
As I said in my earlier post, if this could sanely be done entirely in lua, I'd be all for that, but it can't. So I'd rather extend the main protocol in a clear, well defined way instead of throwing stuff in lua and existing functions just to say we didn't change the protocol. If we use new PTP functions, this will still be backward compatible, old clients won't call them.
Here's my thought on an (IMHO) cleaner way to deal with this.
One new PTP command, PTP_CHDK_GetStreamingData (name subject to change... suggestions ?)
- replaces handle_video_transfer
- input parameters are bit flags defining what should be returned, like handle_video_transfer. The available input params should be enough for pretty much anything we'd want to do, but if you needed more you could have an additional command to select what data is returned by each poll.
- Isn't specific to live view data, that's just one set of things that can be polled. Should also include flags for script status and script messages so a client can just repeatedly poll this one PTP command and get everything it needs in one send. These don't have to be added in the initial implementation though.
- returns all the requested fields with a structure describing their locations. The structure can be very similar to the offset/size handle_video_transfer does now, but rather than implying the meaning of the size/offset fields by their location, they should be matched to the flags that select output.
- The static framebuffer data (from luaCB_get_video_details) just becomes another field that can be selected. Since you no longer need get the function address of handle_video_transfer, you don't need separate function to get this before you start getting video data. You just request this with the first frame, and leave it out later. Not really clear if it really makes sense to separate these values out of the more dynamic ones that have to be sent every frame.
- Compatibility of the returned structures isn't really any different from current implementation, except if we make them chunks that are included in the index structure, we could expand them in a backward compatible way if needed, or define new flags to select different data.
This is more complicated, more code, but IMO would result in a protocol and code we'd be a lot happier living with down the road .
I will try to come up with an implementation of this (edit: if no one else does or convinces me it's a dumb idea) to see if it actually works out like i think, but I'll have to get my head around the C# code or hack live view into chdkptp first.
