<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<p>Wow!  That is astonishing, and well done, congratulations.</p>
<p><br /><span>I've played with it a bit; I had some issues with keyboard problems, and</span><br /><span>it wasn't immediately obvious how to use passwords or ssl.  Of course, I</span><br /><span>suspect those are issues that are relatively easy to address.</span></p>
</blockquote>
<p><span>Keyboard support is one of the most advanced and developed part of the spice web client. By default it is using spanish keyboard, maybe this is the reason you experienced keyboard issues?</span></p>
<p>In fact, we have used this in production (in spain) with no keyboard problems at all, even with special characters, but as i said, always with spanish layouts.</p>
<p>We have included a english layout, but is not as tested and developed as the spanish one.</p>
<p>To use passwords you need to edit run.js to set the password, IIRC there is no url parameter for the token, but can be aded easily.</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<p><span>Rough edges aside, I did note that it was visibly faster than the</span><br /><span>current html5 client for normal usage.  I presume that all your</span><br /><span>optimization of image handling pays off nicely.  I also presume it has</span><br /><span>better support for Windows guests (that would not be too difficult :-/).</span></p>
</blockquote>
<p><span>There are three reasons why it is faster. The first one is because of the image handling optimization. The second one is because it works with qxl activated. The third one is because of the graphical pipeline with almost zero copy. For example, in the queue for the receiving socket, if look at it (socketqueue.js, inside network) there a shadow copy implemented in javascript to avoid copy and gc work.</span></p>
<p><span>It has been optimized a lot for windows with qxl enabled, in fact with windows + qxl and using chromium, the performance is quite close to the native spice client implementation.</span></p>
<p><span>In linux, it is a bit slow on gnome with compositing because of obvious reasons, but is very fast with kde4 with compositing disabled. In fact with kde4 without compositing and using the xorg render the performance is even better than in windows.</span></p>
<p><span>One of our current products use kde4 without compositing and the other one uses windows with qxl enabled, this is why we optimized a lot for this environments/configurations.</span></p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<p><span><span>It's lacking some recent developments; notably support for Opus and</span><br /><span>support for file transfer, although I don't think either of those would</span><br /><span>be especially hard to add.  My most recent video work around rate</span><br /><span>control seems to give the current spice-html5 an edge in video</span><br /><span>performance, at least with Xspice, but that, too, would likely be easy</span><br /><span>to add to your client.</span></span></p>
</blockquote>
<p> </p>
<p><span><span>Wow, thats very interesting. With a linux client using the last chromium connecting to a remote windows guest the performance of video is way better with spice web client than with spice-html5. Maybe you have optimized more for Xspice? We have stil not tested Xspice, neither optimized for it.</span></span></p>
<p><span><span>I don't remember how spice-html5 handles video frames, we do it by using createObjectUrl to not having to encode the jpeg blob with urlencode, this increased the video performance a lot.</span></span></p>
<p>You are right about recent spice features, we would like to have support for the most recent features, but we invested a lot in performance because of requirements of our customers... They were more interested in better performance than in more features, even to a crazy extent.</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<p><span>I am a bit frustrated that you've sprung this, fully formed, upon us.</span><br /><span>The spice-html5 client has been developed, in public, and collaboration</span><br /><span>has been very welcome these past 3 years.  But I do prefer your</span><br /><span>contribution to you keeping it closed instead :-).</span></p>
</blockquote>
<p>Personally I would have prefered to work with you guys improving the spice-html5. However we started this is a startup and our investors disliked opensource and free software a lot... So for us it was impossible to collaborate with you.</p>
<p>Later, we were acquired by Telefonica, the biggest Spanish Telco. We continued to develop our products as telefonica owned company. Telefonica is an active contributor in the Open Source community, its a red hat partner and has a positive view about FOSS.</p>
<p>It took us some time and meetings with Telefonica before we reached an agreement for opensourcing a piece of software like this. I understand that this could have been done better.</p>
<p>Of course, as a developer myself, I really love to be able to contribute with my work of the last 2 years in optimizations of all kinds and support for lots of spice internals (glyphs, scaling, clipping, masking, etc).</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<p><span>Do I guess correctly that this has been your company's main user</span><br /><span>interface for the past several years?  Does that imply that it's been in</span><br /><span>fairly heavy use for some time now?</span></p>
</blockquote>
<p><span>More or less. We have developed a eyeos-agent (like spice-agent) that uses rabbitmq and through this we send coordinates and positions of remote windows. Depending on the customer, we display the entire linux/desktop or just the application that is running there. </span></p>
<p>But yes, it is has been used heavily for the last 2 years.</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<p><span>If you don't mind my asking, what are your intentions with this?  Are</span><br /><span>you hoping to have this become the defacto html5 client for Spice?  Are</span><br /><span>you willing to maintain it and take on community contributions?</span><br /><br /><span>I note the attribution clause in your license.  As it stands now, I</span><br /><span>don't think that would cause any trouble (because of the 'however' of 5</span><br /><span>(d) of the agpl).  But it would probably be useful to get a clear</span><br /><span>expression of your intent - is it the case that you are willing to</span><br /><span>contribute this only so long as the eyeos logo is prominently displayed</span><br /><span>by any one choosing to deploy it?</span></p>
</blockquote>
<p>Our intentions are very simple. We want this to become the defacto html5 client for spice. Of course we want to maintain it and develop it openly. Aside from our obvious personal preferences for FOSS the main reason to opensource it is to develop it in community and of course, we are very excited to discuss the next steps with you and anyone interested in web support for spice :)</p>
<p>And no, we are not willing to have an eyeos logo everywhere this client is used. In fact there is no need for you to display an eyeos logo to use this.</p>
<p>We choosed AGPL because it protects the spice web client from the ASP loophole. We don't want en eyeos logo or something like this displayed every time this client is used, we just don't want for example a third party company adding support for opus in a private product of its own and not contributing it since this can be used from a service provider (ASP loophole in gpl and similar licenses).</p>
<p>However, we are open to discussions about the license if you feel this can be a problem for reasonable scenarios.</p>
<p>I hope this clarified a bit our intentions and position, i know this has been done a bit late :)</p>
<p>Best regards,</p>
<p>joca</p>
<p>On 2015-10-29 17:12, Jeremy White wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">On 10/29/2015 06:38 AM, <a href="mailto:jose@eyeos.com">jose@eyeos.com</a> wrote:
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">Hi,<br /> <br /> We are very glad to announce that today we have released under AGPL3<br /> license our full featured (audio, video, clipboard, qxl advanced<br /> graphics, etc) spice web client.<br /> <br /> The github of the project:<br /> <br /> <a href="https://github.com/eyeos/spice-web-client">https://github.com/eyeos/spice-web-client</a><br /> <br /> Comments are welcome!</blockquote>
<br /> Wow!  That is astonishing, and well done, congratulations.<br /> <br /> I've played with it a bit; I had some issues with keyboard problems, and<br /> it wasn't immediately obvious how to use passwords or ssl.  Of course, I<br /> suspect those are issues that are relatively easy to address.<br /> <br /> Rough edges aside, I did note that it was visibly faster than the<br /> current html5 client for normal usage.  I presume that all your<br /> optimization of image handling pays off nicely.  I also presume it has<br /> better support for Windows guests (that would not be too difficult :-/).<br />  It's lacking some recent developments; notably support for Opus and<br /> support for file transfer, although I don't think either of those would<br /> be especially hard to add.  My most recent video work around rate<br /> control seems to give the current spice-html5 an edge in video<br /> performance, at least with Xspice, but that, too, would likely be easy<br /> to add to your client.<br /> <br /> I am a bit frustrated that you've sprung this, fully formed, upon us.<br /> The spice-html5 client has been developed, in public, and collaboration<br /> has been very welcome these past 3 years.  But I do prefer your<br /> contribution to you keeping it closed instead :-).<br /> <br /> Do I guess correctly that this has been your company's main user<br /> interface for the past several years?  Does that imply that it's been in<br /> fairly heavy use for some time now?<br /> <br /> If you don't mind my asking, what are your intentions with this?  Are<br /> you hoping to have this become the defacto html5 client for Spice?  Are<br /> you willing to maintain it and take on community contributions?<br /> <br /> I note the attribution clause in your license.  As it stands now, I<br /> don't think that would cause any trouble (because of the 'however' of 5<br /> (d) of the agpl).  But it would probably be useful to get a clear<br /> expression of your intent - is it the case that you are willing to<br /> contribute this only so long as the eyeos logo is prominently displayed<br /> by any one choosing to deploy it?<br /> <br /> Cheers,<br /> <br /> Jeremy<br /> _______________________________________________<br /> Spice-devel mailing list<br /> <a href="mailto:Spice-devel@lists.freedesktop.org">Spice-devel@lists.freedesktop.org</a><br /> <a href="http://lists.freedesktop.org/mailman/listinfo/spice-devel">http://lists.freedesktop.org/mailman/listinfo/spice-devel</a></div>
</blockquote>
<p> </p>
<div> </div>
</body></html>