[Spice-devel] spice-protocol "mess"

Yonit Halperin yhalperi at redhat.com
Sun Jan 15 00:13:47 PST 2012


Hi,

On 01/13/2012 02:17 PM, Hans de Goede wrote:
> Hi,
>
> On 01/13/2012 12:17 PM, Alon Levy wrote:
>> On Thu, Jan 12, 2012 at 05:52:15PM +0100, Hans de Goede wrote:
>>> Hi,
>>>
>>> While looking at spice-protocol git, to see if we should
>>> do a spice-protocol-0.10.1 too, I noticed a few
>>> unregularities:
>>>
>>> 1) the 0.10 branch has a commit from Alon called:
>>> "add opus playback and record cap", which is not on
>>> master
>>
>> I don't see anything wrong with adding this, since I'm sure we want to
>> have opus. That said, it shouldn't have been there and I think I pushed
>> it by accident, since I never completed the work on the server and
>> client, and so it's of no use right now. (that happened because opus
>> uses 48KHz and CELT uses 44.1KHz)
>
> Ok, then I suggest reverting that commit for now. I agree it does
> now harm, but it may confuse people into thinking that we do
> have opus support...
>
>>
>>> 2) master has a commit titled:
>>> "Release 0.10.1", but no 0.10.1 tag, and AFAIK we don't
>>> have 0.10.1 tarbals yet...
>>>
>>
>> This is the bump for the mini header support.
>
> I understand.
>
>> You call it adventurous,
>
> It feels adventurous to me I've not looked close enough at it to
> say it really is. I was using the term adventurous in an attemp to
> fish for other peoples opinion on this. But I guess I should be
> more direct. So:
>
> Alon, you think getting the mini header code into 0.10.1 (and thus into
> the next RHEL release) is a good idea?
>
> Yonit, do you feel that you're code is ready for this?
>
I think it is.

>> I think Yonit did all the tests with the new client and the old one,
>> knowing her, but I haven't myself.
>
> I'm sure she did and I wasn't implying the code is untested, just
> that it is rather new and as such has not seen testing by many
> people under different circumstances.
>
>>
>>> So we need to sort this out, I suggest:
>>> 1) Adding the "add opus playback and record cap" to
>>> master.
>>> 2) Cherry picking the 3 commits in master but not in
>>> the 0.10 branch into the 0.10 branch
>>> 3) creating a 0.10.1 tag on the 0.10 branch
>>>
>>> I wonder though, are we sure there are no adverse
>>> effects of bumping SPICE_VERSION_MINOR to 2? This seems
>>> like a bit of a risky chance to make in a 0.10.x
>>> release. Are we sure all clients and server versions
>>> will grok connecting to / getting a connection from
>>> a server / client with a different minor then themselves?
>>>
>>
Connection is refused only if the major is different. As I see it, the 
minor is somewhat redundant and implicit way to define capabilities...
I did perform tests of the patches for old-client connecting to new 
server, and new client (spicy) connecting to old server.

BTW, Yaniv, can you update the wireshark dissector to handle the new 
protocol?

Yonit.
>> I'm not sure. Someone needs to check.
>
> Right, which is why I called the code adventurous :)
>
> Regards,
>
> Hans
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel



More information about the Spice-devel mailing list