What will be the policy regarding Plugin Updates over time?
By that I mean will future versions of the plugin retain backward compatibility and work with existing installations of x2go?
It seems the browsers are always pushing users to upgrade their plugins so they have the latest functionality and security fixes. But this can also mean that existing installations that work with the newer plugin versions could also need updating as well unless the plugin is always sure to be backward compatible.
What is the x2go policy in regard to plugin updates and backward compatibility?
Regards, Gerry
Hello Gerry,
Am 15.09.2010 17:08, schrieb Gerry Reno:
By that I mean will future versions of the plugin retain backward compatibility and work with existing installations of x2go?
We've tried to save the compatibility for all now existing versions of x2go. As x2goplugin is basically "x2goclient", we'll go on trying to provide a basic compatibility of future versions.
It seems the browsers are always pushing users to upgrade their plugins so they have the latest functionality and security fixes. But this can also mean that existing installations that work with the newer plugin versions could also need updating as well unless the plugin is always sure to be backward compatible.
Other than for extensions, mozilla does not provide webspace for plugins. So the plugin will be hosted on our server (or where you want). We'll provide a SSL update site.
What is the x2go policy in regard to plugin updates and backward compatibility?
Since we are planning to change to QtPlugin instead of our own implementation, some things may change. After the first steps we've taken, the place where to store the plugins options may change from "a single file" to "inside the presenting website".
best regards,
Heinz
On 09/15/2010 01:07 PM, Heinz-M. Graesing wrote:
Since we are planning to change to QtPlugin instead of our own implementation, some things may change. After the first steps we've taken, the place where to store the plugins options may change from "a single file" to "inside the presenting website".
So this would be doing something like using QtNPBindable::readData() to read a 'server.x2go' file from the 'data' attribute url in the 'object' tag?
Can you elaborate about 'inside the presenting website'? Do you mean that the 'server.x2go' options file would be located under the docroot of the presenting website?
Regards, Gerry
-
Gerry Reno -
Heinz-M. Graesing