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
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel