[Spice-devel] [PATCH spice-protocol V2] vd_agent.h: drag-and-drop support

[Dunrong Huang]

Hi,

>> >> 1) For file information, use a key-value text passed from client
>> >> to
>> >> guest instead of using stuff that is hard to extend.
>> >>      I like this approach too, :-).
>> >>
>> >>     So VDAgentFileXferStartMessage will become:
>> >> typedef struct SPICE_ATTR_PACKED VDAgentFileXferStartMessage {
>> >>     uint32_t id;
>> >>     uint64_t size;
>> >>     uint8_t data[0];
>> >> } VDAgentFileXferStartMessage;
>> >>
>> >
>> > I assume size here is the file size in bytes ? One could argue this
>> No, size is combined data size, not file size.
>
> The key-value data size? then a uint32_t is really big enough, but that is a detail.
>
>
>> > belongs in the key-value text too. But this one is special because
>> > it
>> > needs to exactly match the combined size of the data messages send
>> > later,
>> > so I think having it separately makes sense, so ACK (acknowledge /
>> > I agree) for that.
>
> I agree with Hans that it would make sense to have the combined data messages size in the VDAgentFileXferStartMessage. However, I am concerned that once the data is compressed, that field may have a different meaning (either the compressed size which will be bad to compute in advance, or the unflatten size which will not serve the original purpose). Anyway, if the client is misbehaving, there is nothing the server/agent can do to prevent it flooding with invalid messages. All in all, I would tend to think it's not required here.
>
Oops, I confused message size with data size :-). And yes, you are
right, we do not need this filed.
>> >> Hans and Marc-André,
>> >> Whether patch V3 is welcome or not, or something need to be
>> >> discussed?
>> >
>> >
>> > I believe a v3 is welcome, but lets wait for Marc-André's input.
>> >
>> Marc-André, any suggestion?
>
> Any further iteration is always welcome!
>
> thanks again



-- 
Best Regards,

Dunrong Huang