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? 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. We have included a english layout, but is not as tested and developed as the spanish one. 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.
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. 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. 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. 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.
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. 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. 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.
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. 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. 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. 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).
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. But yes, it is has been used heavily for the last 2 years.
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 :) 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. 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). However, we are open to discussions about the license if you feel this can be a problem for reasonable scenarios. I hope this clarified a bit our intentions and position, i know this has been done a bit late :) Best regards, joca On 2015-10-29 17:12, Jeremy White wrote:
|
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel