What's Next? Future of UVNC.

redge · Post by **redge** » 2005-07-13 03:18

a must have like "DirectVNC"
+DirectFB hardware accelerated)

made possible with Windows too UltraVNC 2 ?

http://www.adam-lilienthal.de/directvnc/index.html
hardware direct frame buffer ressource
http://www.directfb.org/

Post by **Oliver** » 2005-07-13 03:35

californiajeff wrote:Well, the reason I suggested it is because are we talking a major overhaul to redo the codebase? Is this something that could take many months or are we talking a few weeks? We might want to keep the new code seperate until it is completed because bugs and fixes might come up for the existing 1.0 release. Just a thought but I'm not the expert. We would need to hear the insight of those that are doing the programming.

So what you want is some kind of "codename" for the later product???

redge wrote:add Unicode as base of UltraVNC 2 code support.

Definitely. Maybe we should even think about the server binary only compatible with NT platform (complete unicode).

red wrote:I may be interested in getting this going for you or at least partially. I currently get paid to do this for someone else so I have to make sure it would be OK to do this...I'm pretty busy right now so it might take me a while, but I will get back to you if there is interest.

This would be great. If you could provide some contact info?!

netwolf · Post by **netwolf** » 2005-07-13 08:11

Oliver wrote:
redge wrote:add Unicode as base of UltraVNC 2 code support.
Definitely. Maybe we should even think about the server binary only compatible with NT platform (complete unicode).

AFAIK there is something like a Unicode addon for Win9x platforms
(haven't used any 9x for quite a long time, so I'm not sure about that...)

Post by **Oliver** » 2005-07-13 08:53

netwolf wrote:AFAIK there is something like a Unicode addon for Win9x platforms
(haven't used any 9x for quite a long time, so I'm not sure about that...)

There is, you are right. However, it is a very rudimentary support for Unicode. So it's nothing you'd want to use. And anyway the future of MS' OSs is the NT platform ...

Post by **Oliver** » 2005-07-14 19:16

64bit-compatbility should be a goal, too. I mentioned this in the dev-forums already, don't remember if I did so in the public fora as well.

redge · Post by **redge** » 2005-07-15 20:26

any equivalent of directFB hardware accelerated ?

is there no better or equal improvement about DirectX hardware acceleration aka like Avalon.net for Longhorn for Remote control computer versus like X-DirectFB from Linux?

I have difficult to believe there no improvement about that !
remote working or remote support is not made yesterday on windows plateform.

Zhrakkan · Post by **Zhrakkan** » 2005-07-21 18:18

Greetings all.
Been around UVNC for awhile, and using it off and on for awhile. I am quite excited to see it finally Mature to a V1 release. WOO WOO!

Now, my thoughts. I am not a programmer at all. I am a Network Administrator and the local techie for many people.

I see the following issues (In this order)

Open the Developer Base
If we have a GOOD control of the code, then start bringing in a) fresh blood and b) More developers to trully assist in code developement, site maintenance, project management, etc...
Just an observation (I may not be correct here, so please, no flames on this issue) is that the development seems a little on the slow side because its only done by a few people. I myself have left and come back to UVNC a few times because it never seemed like anything was getting done....

Security
I am a security buff. If I connect to someone using a remote tool, I want it damn secure (we all know things are not 100% secure...)
I would love to see a group of individuals, brought in or at least, a secondary group sub-divided out, to resolve and/or develop security related items. For instance, upgrading possible plugins, and or some sort of high-end encryption between point-to-point. This group, could devote all time to just Security related issues in development and simply just explore any possible avenue to grow into the product. This is also a HUGE marketing tool.

Marketing
Some people may find this a funny "future desire" for me to say. I think, when we bring in some new people, from the first option, we also bring in some people who can try to devote some ways to market UVNC in ways FireFox was done. This will help in the long run of possibly getting new blood to help in its development and many other things.

Backward Compatability
This is not a huge issue with me personally, since I use UVNC across the board. But I believe this is a huge selling point. That being said. I believe we might be able to maintain backward compatability while implimenting new feature for version 2.0. All the while, working on new more efficient code (as some people put it previously). This code can be slowly worked into the 1.x version, or slowly, building a completely new version with the new backend.

More Powerful Installation Options
One thing I personally would love to see, and would be a huge benefit to those using it on a more "global scale" would be a huge more configurable installation script. Basically the ability to configure EVERY option upon the install to allow the client to do nothing but possibly change a password upon connecting the first time. (this is a great marketing tool, to get more people to use it)

What I dont see are needing change or what not
I dont believe SOUND is needed to be transported. This would be a cool feature, but unfortunately, I see no huge benefit in it.[/b]

Post by **Oliver** » 2005-07-21 18:43

Zhrakkan wrote:Open the Developer Base
If we have a GOOD control of the code, then start bringing in a) fresh blood and b) More developers to trully assist in code developement, site maintenance, project management, etc...

Definitely!
But it is not sure, whether the codebase will be "dropped" (of course not completely) and only some features "ported" to version 2.0. We could use RVNC 4.0 as the codebase then and keep our code relatively separate from it. So it's easy to move to another codebase lateron.

Zhrakkan wrote:Just an observation (I may not be correct here, so please, no flames on this issue) is that the development seems a little on the slow side because its only done by a few people. I myself have left and come back to UVNC a few times because it never seemed like anything was getting done....

Not any flame war has been observed on this forum, yet

Only two developers, but many wishes. IMO it was not that nothing was done - too much has been done. For example they promised to not introduce any new features until version 1.0 - this was not fulfilled. So version 1.0 deadline was postponed all the time.

Zhrakkan wrote:Security
I am a security buff. If I connect to someone using a remote tool, I want it damn secure (we all know things are not 100% secure...)
I would love to see a group of individuals, brought in or at least, a secondary group sub-divided out, to resolve and/or develop security related items. For instance, upgrading possible plugins, and or some sort of high-end encryption between point-to-point. This group, could devote all time to just Security related issues in development and simply just explore any possible avenue to grow into the product. This is also a HUGE marketing tool.

And this is a HUGE problem. We act internationally and no one of us thinks it would be nice to end in a stinking prison just because we "exported weapons" (cryptography) - and all this because we were "stupid enough" to do all this work voluntarily.

Zhrakkan wrote:Backward Compatability
This is not a huge issue with me personally, since I use UVNC across the board. But I believe this is a huge selling point. That being said. I believe we might be able to maintain backward compatability while implimenting new feature for version 2.0. All the while, working on new more efficient code (as some people put it previously). This code can be slowly worked into the 1.x version, or slowly, building a completely new version with the new backend.

What for? What for do you want to keep compatibility? And with which version? I personally talk especially about the driver. And tell me: which driver do you use in conjunction with which version of the server? It has been a mess. This has to be changed. Viewer compatibility (even with non-UVNC viewers) will not be dropped anyway.

Zhrakkan wrote:More Powerful Installation Options

I am a network admin, too. So this is a strong point

Zhrakkan · Post by **Zhrakkan** » 2005-07-21 18:59

Definitely!
But it is not sure, whether the codebase will be "dropped" (of course not completely) and only some features "ported" to version 2.0. We could use RVNC 4.0 as the codebase then and keep our code relatively separate from it. So it's easy to move to another codebase lateron.

OK, a Misstep of communication on my part. When I meant
"If we have a GOOD control of the code, then start bringing in a) fresh blood and b) More developers to trully assist in code developement, site maintenance, project management, etc..."

I meant, if there a a good 1 or 2 people who are in charge of the overall project and the code behind it, we could have 100 developers and be good to go. I didnt meant to specify the codebase as pointing to the code and how it works. Simply more people would work if we have a good "project manager" of the code development"

Not any flame war has been observed on this forum, yet Smile
Only two developers, but many wishes. IMO it was not that nothing was done - too much has been done. For example they promised to not introduce any new features until version 1.0 - this was not fulfilled. So version 1.0 deadline was postponed all the time.

Again, we come into having a good Project Manager who can help determine "in scope" and "out of scope" issues. They can fit some quite new bits of functionality in or not, depending on timelines, workload, etc....
This is too much for 2 people IMO. 2 people handling it all, can be done, as you can see..... but would make life I think easier, if more were on board and working the issues.

And this is a HUGE problem. We act internationally and no one of us thinks it would be nice to end in a stinking prison just because we "exported weapons" (cryptography) - and all this because we were "stupid enough" to do all this work voluntarily.

*growl* Damn Export Compliance! I would still like to find out how far this can be pushed legally.... just my thoughts since I am such a encrypt all my network traffic putz when it comes to the remote control stuff...

What for? What for do you want to keep compatibility? And with which version? I personally talk especially about the driver. And tell me: which driver do you use in conjunction with which version of the server? It has been a mess. This has to be changed. Viewer compatibility (even with non-UVNC viewers) will not be dropped anyway.

Like I stated, I really only use UVNC...so where it goes, compatability is not an issue to me... But I can see a huge benefit, of the ability to maintain backwards compatability to RealVNC, or whatever VNC versions there are (you guys know more about this than me) But a date/time/version can be established, for a future time, that simply says, come this time, we no longer will have compatability to anything other than UVNC....

I am a network admin, too. So this is a strong point Wink

Yeah, I would love to be able to completely have the install custom installed with all options exactly as I want them, with maybe one exception, a default password, which of course I can change upon the first login.

Post by **Oliver** » 2005-07-21 19:09

Zhrakkan wrote:OK, a Misstep of communication on my part. When I meant
"If we have a GOOD control of the code, then start bringing in a) fresh blood and b) More developers to trully assist in code developement, site maintenance, project management, etc..."

I meant, if there a a good 1 or 2 people who are in charge of the overall project and the code behind it, we could have 100 developers and be good to go. I didnt meant to specify the codebase as pointing to the code and how it works. Simply more people would work if we have a good "project manager" of the code development"

Okay. In this case full ack

Zhrakkan wrote:Again, we come into having a good Project Manager who can help determine "in scope" and "out of scope" issues. They can fit some quite new bits of functionality in or not, depending on timelines, workload, etc....

No one of us does this as a fulltime job. Sharing the work is the first step. Subdividing the project is the next one. Merging everything is the last step.

Zhrakkan wrote:This is too much for 2 people IMO. 2 people handling it all, can be done, as you can see..... but would make life I think easier, if more were on board and working the issues.

Fully true.

Zhrakkan wrote:*growl* Damn Export Compliance! I would still like to find out how far this can be pushed legally.... just my thoughts since I am such a encrypt all my network traffic putz when it comes to the remote control stuff...

... we need to consider this however

Zhrakkan wrote:Like I stated, I really only use UVNC...so where it goes, compatability is not an issue to me... But I can see a huge benefit, of the ability to maintain backwards compatability to RealVNC, or whatever VNC versions there are (you guys know more about this than me) But a date/time/version can be established, for a future time, that simply says, come this time, we no longer will have compatability to anything other than UVNC....

Something I already stated in one of the (hidden) dev-fora. Yes we need to completely overhaul the versioning of the app+driver. What is UVNC? Is it the server - because if the mirror driver? Is it the viewer? If it is the server you need not maintain compatibility to older versions of the driver or vice versa. This is simply not needed.
The viewer will be fully compatible with any other VNC taste and consequently the server will be. But compatibility to older server versions should only exist as far as necessary. Else we have to maintain two codebases in the worst case!

Zhrakkan wrote:Yeah, I would love to be able to completely have the install custom installed with all options exactly as I want them, with maybe one exception, a default password, which of course I can change upon the first login.

This is a project to come. Please be patient however. The biggest (IMO) current problem is, that the driver cannot be bundled on SF.net with the rest of UVNC. This is IMO the first to be solved.

Zhrakkan · Post by **Zhrakkan** » 2005-07-21 23:50

I thought of another HUGE reason as to why the Development group should be increased.

UVNC has the ability for Plugins. This is another MASSIVE benefit for the application.

Brinigng in more developers will most likely increase the number of possible plugins built for the application.

Guest · Post by **Guest** » 2005-07-22 19:17

Zhrakkan, you talk as if anyone is stopping developers from joining the project, which is false...

I think you forget the fundamental thing which is that this is an open source project on which everyone who wants to contribute does it for free. If you start offering money, I can ensure that programmers will come in dozens.

It is not a question of project management, as there are basically only two programmers in this project and would be difficult to get project management wrong in this case.........

it is a question of attracting more developers. The chances are there as the open plug-in structure. So I think that anyone is free to participate.

Post by **Oliver** » 2005-07-22 19:30

Anonymous wrote:it is a question of attracting more developers. The chances are there as the open plug-in structure. So I think that anyone is free to participate.

It was quite open, but since Rudi and Sam did it themselves no one really cared. Marscha is dev for one of the plugins for a while. I'll be responsible for the new mirror driver ... and so on. So there are more than 2 already.

And yes, I agree, project management is an issue as soon as more than 2 devs exist. There should be one for the overall project and several for sub-projects. And a group which works then on a sub-project.

californiajeff · Post by **californiajeff** » 2005-07-26 19:15

Oliver wrote:
californiajeff wrote:Well, the reason I suggested it is because are we talking a major overhaul to redo the codebase? Is this something that could take many months or are we talking a few weeks? We might want to keep the new code seperate until it is completed because bugs and fixes might come up for the existing 1.0 release. Just a thought but I'm not the expert. We would need to hear the insight of those that are doing the programming.
So what you want is some kind of "codename" for the later product???

I think a "codename" would be an excellent idea.

Oliver wrote:
redge wrote:add Unicode as base of UltraVNC 2 code support.
Definitely. Maybe we should even think about the server binary only compatible with NT platform (complete unicode).

What advantages would we achieve by having a server binary that is only compatible with the NT platform? I do have most of my stuff on XP now and I am working on replacing all my 98 and NT machines but that takes time and money (I am lacking money more than I am time).

californiajeff · Post by **californiajeff** » 2005-07-26 19:24

Oliver wrote:64bit-compatbility should be a goal, too. I mentioned this in the dev-forums already, don't remember if I did so in the public fora as well.

I agree.

Post by **Oliver** » 2005-07-26 19:32

californiajeff wrote:What advantages would we achieve by having a server binary that is only compatible with the NT platform?

Full Unicode support. This is especially important if your files have file names which are in different languages and you want to use the FT!

californiajeff · Post by **californiajeff** » 2005-07-26 19:52

Oliver wrote:
californiajeff wrote:What advantages would we achieve by having a server binary that is only compatible with the NT platform?
Full Unicode support. This is especially important if your files have file names which are in different languages and you want to use the FT!

Makes good sense! We should push for that goal then. We could still leave the 1.x program available to download for those with older machines.

redge · Post by **redge** » 2005-11-20 12:04

SPECencoder, read post of lizard
[topic=2959][/topic]

resuming new UltraVNC V2 project

UltraVNC V2 (easy to be ported as cross plateform) +sound+print
RTP+LZO+SPECencoder+raknet+irrlicht+RDP +NTLM <- for connect to windows.

RTP = Real Time Protocol

LZO = Lempel-Ziv-Oberhumer (realtime and portable lossless data compression

SPEC = Shape Primitive Extraction and Coding

NTLM = is an authentication protocol used in various Microsoft network protocol implementations and supported by the NTLM Security Support Provider ("NTLMSSP") http://davenport.sourceforge.net/ntlm.html
the basis for the implementation of NTLM in the open-source jCIFS library, available at http://jcifs.samba.org.

raknet = A free networking API that provides reliable UDP and high level networking constructs on Windows, Linux, and Unix

irrlicht = The Irrlicht Engine is an open source high performance realtime 3D engine written and usable in C++ and also available for .NET languages. It is completely cross-platform, using D3D, OpenGL

like a french word: mécène
if I have big money to donate, I would suggest to create a staff developpers for high school university for developping under exclusive free license GNU with help of staff manager of UltraVNC strong quality professional level.

it time to begin at year 2006 ...
you have everything to begin except money and time ?

UltraVNC

What's Next? Future of UVNC.

My thoughts on Future Development

Re: My thoughts on Future Development