Hi there ,
First of all I have to thank everybody that has contributed to create and enhance UltraVnc. It is great.
What I noticed though that with the rapid development of new versions the stability of the product is decreasing and there are always more issues (some on the server, other on the browser).
This is why I am still using 1.0.4 (on the server side).
I am not sure what in the development process create this problem. Maybe since the features are increasing and different modules of the code tightly interact with each other it is easy to break something else when something else is fixed.
Let me humbling suggesting how to I think this can be improved. You can think about introducing one or more of these practices:
(1) - Better versioning
Problems:
Sometimes I saw patches released "on fly".
They don't show up on the website and they sometimes have the same version number or it is not clear what the update is unless you carefully read the forum.
Moreover it is not clear if the patch is propagated on the next version.
In order to find out what works, the user has to test by himself different configurations.
Plus I am not sure if all the contributors to the project has always the last version of the source code.
Now that the number of versions are increasing is becomeing more complicated to know what happend with a new viewer and a older server and viceversa.
SOLUTIONS:
Using Google Code (effectively) will be the quickest way to help with both the following, but feel free to set up your own servers if you want.
1 - Always use a versioning system:git or subversion are good. Google code has subversion. It is necessary to invest some times to learn how they work if you haven't use them on a consistent basis, yet. But they pay off. I would suggest to have a different folder for each exe and plugin(VNC server, VNC viewer, VNC Viewer DirectX, encryption plug-in, etc). Label every released change with a progressive version.
In alternative to Google code I saw there is http://sourceforge.net/projects/ultravnc/files/(that is already there) but I think it has not been used effectively.
2 - Create a Wiki. In this way developers and users can help to document incompatibilities (specific version server with a specific version viewer) and bugs, etc. Google code has one already. It has also a bug tracking system. The forum is nice but it is difficult to keep track of bugs etc. And it also easy to create guide on HowTo
3 - Maintaining compatibility I think a good practice would be to always keep compatibility of the viewer with older servers at least. It is not always easy to replace the server from remote.
(2) - Better testing
Problems:
It looks likes new features and bug fixing sometimes create new bugs.
It is also not clear when a bug is solved or not. Sometimes a old bug pop again in a new version.
When you have been working on project for years, the amount of code grew a lot, and you had to switch between multiple projects it is difficult to remember what does what and how interact with other modules (especially if these modules have a tight interaction).
SOLUTIONS:
1 - Create Automatic Unit Tests: They can test some basic assumptions on what a piece of code has to do. They can be run before a realease is made.
2 - Create test procedures (better if the can be automated). Like writing what are the step that have to be done to test a specific bug that should be solved.
I know by experience that creating a test set is very tedious (especially) if you didn't start since the beginning. But the practice help to really keep a robust code.
3 - Keep clear comment on the code. If you do something "smart" but not so immediate document that with a short comment. You are probably already good with that. I didn't look at the code... but hey.. it is just a reminder
Well, I hope my suggestions are appreciated.
You don't have to stop developing now and do ALL what I wrote before in order to reap the fruits. You can easily try one thing at the time. As I already wrote Google Code can help to get a lot done quickly. They have been committed to develop state of art tools to make the like of the developer easier so they can focus on what they like to do.
Let me know if I can help with something. I really like UltraVNC and I would like to help to make it more stable and robust.
Best,
Chris
Update: UltraVNC 1.4.3.6 and UltraVNC SC 1.4.3.6: https://forum.uvnc.com/viewtopic.php?t=37885
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Important: Please update to latest version before to create a reply, a topic or an issue: https://forum.uvnc.com/viewtopic.php?t=37864
Join us on social networks and share our announcements:
- Website: https://uvnc.com/
- GitHub: https://github.com/ultravnc
- Mastodon: https://mastodon.social/@ultravnc
- Facebook: https://www.facebook.com/ultravnc1
- X/Twitter: https://x.com/ultravnc1
- Reddit community: https://www.reddit.com/r/ultravnc
- OpenHub: https://openhub.net/p/ultravnc
Some suggestions how to improve UltraVNC realiability (dev)
Re: Some suggestions how to improve UltraVNC realiability (d
I have to concur with Cris' general thoughts, at least... (I'm not a big fan of automatic unit tests in practice).
Still, the rest holds, in any case. Building this project is difficult, to say the least (OK, not specifically building it, but rather setting it up for build). The mix of open source, and non-open source seems arbitrary, at least.
I understand the difficulties of managing an open-source, or any other development project... I just wish that this one _were_ managed
Still, the rest holds, in any case. Building this project is difficult, to say the least (OK, not specifically building it, but rather setting it up for build). The mix of open source, and non-open source seems arbitrary, at least.
I understand the difficulties of managing an open-source, or any other development project... I just wish that this one _were_ managed