What's Next? Future of UVNC.

[Terriff]

Now that we have an official version 1.00 (congratulations!!), I'm wondering what the priority list is for new features.

I am eagerly awaiting many additions that have been discussed in the forums as I'm sure are many others.

I know that you've JUST released it and probably would like a little break. I'm not trying to rush or anything, I'm just really looking forward to the future of UltraVNC.

Would it be possible to get a high-level overview of the next planned feature implementations?

Thanks UVNC team!

[mod=2,1119959755]Made the title a little more meaningful[/mod]

[Rudi De Vos]

**Rel1.00: No new addons, only fixing some remaining bugs.
**Beta2:
Every thing is possible

*Do we maintain compatibility ?
*Realvnc 4.0 base ? Best parts of code are in the enterprise version..
*Break everything...split code in modules ?
If the number of developpers would increase, working with modules
makes it easyer.
*A full remake ?
*Tcp/ip --> move to rtp ? Real multi viewer support.

................................................

[netwolf]

*Do we maintain compatibility ?
*Realvnc 4.0 base ? Best parts of code are in the enterprise version..

IMO it would be desirable to keep compatibility as long as possible
I'm not familiar with the underlying protocols, but isn't it e.g. possible to introduce some new flags, opcodes or similar for new features in order to use them, but not break compatibility with other/older VNC flavors (as they don't understand and therefore just ignore them) ?

WRT RealVNC code base: yes, IMO it is important to update codebase to 4.x, as it would allow UVNC to get rid of some legacy limitations.

And the changelogs contain some nice goodies (even the free editions)

http://www.realvnc.com/products/free/4. ... notes.html
http://www.realvnc.com/products/free/4. ... notes.html
http://www.realvnc.com/products/free/3. ... notes.html

[UltraSam]

I would also consider starting beta based on RealVNC4 enterprise codebase, but being carefull with encryption parts...

Then we can port all the Ultr@VNC specific functionalities:

- FileTransfer (new improved one with tons of new stuff, more user friendly, presumably not backward compatible with V1. Have to think about it). The V1 FT part is going to be maintained/improved in the upcoming weeks anyway.

- Chat (+ voice chat ?...)

- Video Driver (under BSD ?)

- DSMPlugin: if still necessary. Maybe a better techno. will be used.

- MS Logon

- Toolbar

- Screen Blanking

- New high perfs encodings for slow connections

- Bitmap cache (improved one)

- Integrated proxy/repeater

...

[lizard]

modularize -> API exportation/plugin ability so UltraVNC can communicate with external technologies?
sound transport / voice chat?
new fast & high compression encoding or caching method?
super-SC lite version secure and easy for support purpose?
.NET language ports?

even as watching from outside, thanks to these amazing developers i can imagine truly anything with UltraVNC!
why don't you keep up with world best WinVNC.

[Oliver]

My first suggestion: open the team so interested people can join development. SF.net allows for finetuned permissions for developers (and the other positions in a team). Of course the team should not become overcrowded, but new people would allow for faster development/release cycles. Furthermore this would require the project to become more disciplined (alone because of more developers). Currently the users sometimes have no idea wich version/build/RC corresponds to which driver and so on. Let alone the fact that "no new features" should have been implemented, but more and more new features were implemented before Rel 1.0!
The driver should be rewritten (Rudi will not open his code for good reasons) to have the possibility to bundle it with the usermode binaries. One guy from Russia already contacted me about the video mirror driver. Nevertheless Rudi could still maintain his version (additionally having the chance of discussion with a second driver devel team) so that we could choose between two different driver versions, whereas one can be bundled without problem. Furthermore it is no problem for a company to bundle the GPLed code with their product as long as the source code is published along. This might even get some fast progress into the mirror driver development (companies have to publish their changes as well!). AFAIK the RealVNC and other VNC teams were searching for a mirror driver a while ago ( - and still?!).

BTW: The driver will be GPL (almost for sure). BSDL allows to many things, which means we give away rights that should better stay in our hands (literally - the GPL of course takes it away from us and passes it to "the community"). Companies are more reluctant in using GPLed code because strings are attached. BDSLed code gives them full choice what to do. Perhaps we should agree on this before checking in the first version anyway. I also think that putting it under BSDL would be unfair to Rudi because he developed his code and shared the binaries all the time, but other companies could use the BSDLed code without restrictions. So GPL is the better choice here. Last but not least the whole project would be under GPL (including driver).

If you move to the RVNC 4.0 codebase that would be a good chance to have the driver rewritten from scratch. Else I am always creeping behind ... IMO this could be used to rethink the current driver/usermode interface and possibly make some changes.

Actually I am in favor for codebase change. This would also allow to consolidate the UVNC codebase.

@Rudi: do I have CVS access already?

[Rudi De Vos]

Just wondering,

Would the irc.freenode.net not a better way to talk about the future.

I realy think that current code base and Real4.0 is to complicate.
With different developpers we need to split in subprojects

Network: This should be complete seperate..
The network make the connection, plain, invers, tcp, multicast...
Vnc should not be aware of how the connection is made, he only see 2 buffers and some status incications: incoming, outgoing,want new data, data waiting, connection status
So every body could make his own module, plugin and use the vnc engine

Service: We need to prevent using an interactive service.."Not longer supported in Longhorn"

Encoders: seperate, with defined input/output.
I should be possible to write a new encoder without knowing anything about the rest of the code.


........

If this is possible with Real4.....i agree using Real4
If not, we better consider something else.

[Oliver]

I am online in the IRC channel. Waiting for you, Rudi

[Rudi De Vos]

I'm still @work

I will be on line in 3 hours 18:00 forum time (20:00 belgium time)

[Oliver]

I'm still @work

I will be on line in 3 hours 18:00 forum time (20:00 belgium time)

Okay I'll try then (maybe after 21:00 only). It's also CET + DST in Belgium, I believe.

[lizard]

INTERNET
^
[Network Module] <-plugin- [Encription Driver]
^
[IO Event Manager] <=plugins= [Feature Cores]

Network Module:
Network.SimpleTCP ... includes client/server
Network.SimpleRDP ... as well
Network.COM ... yes, possible lol
Network.WhateverP2P ... wanna see someday

Encription Driver:
Encription.Raw ... no encription
Encription.MD5
Encription.AES

Feature Drivers:
Feature.VNCCore ... remote control
Feature.CommDriver ... communication
Feature.FT ... platform-free FT

[VNCCore] <-plugin- [*Auth]
Auth.Password ... plain text/ no pass
Auth.MD5 ... MD5 Challenge
Auth.MSLogon
Auth.Radius

[VNCCore] <=plugins= [*Encodings]
Encoding.Raw ... comp option not available
Encoding.ZlibHex ... equivalent to Hextile with comp option off
Encoding.Tight ... only to use Lossy option
Encoding.XOR
Encoding.ZRLE
Encoding.Ultra ... comp level not available?

[CommDriver] <=plugins= [*Comm]
Comm.Text ... text chat
Comm.Sound ... sound transmission/ voice chat
Comm.Video ... video transmission

modules communicate with XML markups.

wow it sounds like multi-purposey networkey solutionnn now! takes forever to get done :p
even not, we better re-construct the whole thing and maybe use a modern language to develop the new thing so we can maintain the code well and perhaps to make a big successful party?
i mean how many's learning like C#, VB.NET or D these days?

[Oliver]

Encription.MD5

How will you get decryption done with MD5-hashing?

wow it sounds like multi-purposey networkey solutionnn now! takes forever to get done :p
even not, we better re-construct the whole thing and maybe use a modern language to develop the new thing so we can maintain the code well and perhaps to make a big successful party?
i mean how many's learning like C#, VB.NET or D these days?

Drivers won't work in these languages anyway. Furthermore some of the features are questionable (e.g. sound) and we should ask ourselves whether we want UltraVNC as an enhanced version of VNC or whether we want an alternative RDP client/server system

The fact that UVNC is so small (one binary for viewer, one for server) and so fast makes it so cool. The driver can be easily put into the server binary to be extracted by the server (as soon as licensing is compatible). I have used such methods and could easily extend this. (Sysinternals uses this method in several of their tools!)
Optionally a server could be compiled to work with external plugins or with plugins compiled into the binary.

IMO FT could be changed to tunnel SMB connections in conjunction with the MS-Login plugin. Perhaps this is one of the plugins to be merged into the main UVNC code anyway which would allow for two possibilities in FT: something like FT now (seems like TFTP?!) and additionally SMB (CIFS).

[UltraSam]

Ok. Discussion is open

I won't be able to connect to the IRC channel this evening: not at home.

And I prefer the forum

[Oliver]

Okay, let me summarize from the chat:

• modular design of the codebase (no matter whether RVNC 3 or 4)
  This includes to split the project into parts which can be split easily.
• Open the team (CVS direct access) to more cool developpers (Oliver, Marsha, lizard... ?) (Sam speaking )
• Sound possible but least priority
• File Transfer needs rework
• Driver published under GPL (i.e. a complete rewrite necessary)

The superior GUI is considered one of the main advantages of UVNC over any other VNC flavor!

Open question: which codebase? RVNC 3 or 4?
-> Still the possibility of complete rewritting from scratch. We still have to have a look at the RealVNC4 Ent. codebase...

Rudi & Sam, please edit my post to add other things

[lizard]

my answer to [post=12846]the driver problem's solution[/post]. please read.

[Oliver]

Nicely done. Let's see how we can implement this in the restricted environment of display drivers.

[californiajeff]

The future of UltraVNC is bright!!! I have lots of ideas!

First off, no matter what we must never ever break compatibility. That would be the kiss of death! That is one reason why I hate Java. Sun broke compatibility with earlier versions. If we must break compatibility to move into a new direction I suggest we start a sister project like what Mozilla did with Firefox.

Also, I think we should remain compatible with VNC unless you want to take on the task of developing versions for Linux, Mac OS X, etc. I don't think we are ready for that yet.

The top things I would like to see:
1.) Sound implemented (this would make UltraVNC light years ahead of everyone else!)
2.) More Enterprise Level features (i.e. like VNCon even if it would need to be done in a side project)

More ideas to come as I have run out of time for posting.

[Rudi De Vos]

Maintaining compatibility is actual
If compatible
{
current sourcecode Ultravnc or Realvnc
}
else
{
use new code
}

Making internal switches for all functions is a hell to program
I realy do not know if we need it during beta testing, if beta become stable
we always can add the first part of the if..

Non of the new addons will work with other oS viewers anyway.

[redge]

lzo+rtjpeg+rtp +voip(SIP?)

are very welcome audio for professor or reseller, student, family, friends

example of interesting usage

- demo show room, virtual class room , professor classroom, student demo:
http://www.exploratorium.edu/gardening/index.html
many demo makers create Flash that not realistic with remote demo
(miss audio and miss smothing) and network bandwith need
Rudi wrote: RTP also can give some advantage for long distance connections (less latency)"

- push to browser
so student or customer don't need to download first and watch later, but pushed to browser like php so no need to download any plugin.

- remote support + sound full duplex
(for technical support), remote support voicemail
speak to customer or anybody speak to technician can explain togueter for faster fix than writing (because so many users are very slow writers)

remote control own computer+sound+print
(only one way sound needed (less bandwith)
like you stay at your office or home, without missing all need.


So, developpers you have great idea and select the best way need as simple and easy for deloping and debugging.
(but, please, care speed of performance code and quality.
not like high end Java language are so slow performance that make the software very less interesting for end user customer even software "easy" to debug for developer that can broken all effort)

[Oliver]

First off, no matter what we must never ever break compatibility. That would be the kiss of death!

I partially disagree. Why? Well, first of all we are thinking to change the codebase and back/foreporting can be much more tedious than coding from scratch.

Second, if you talk of compatibility with the VNC protocol, I believe this is no question. This will be maintained. You will be able to watch it from either a standard VNC viewer or the one which comes with UVNC.

Also, I think we should remain compatible with VNC unless you want to take on the task of developing versions for Linux, Mac OS X, etc. I don't think we are ready for that yet.

X works completely differently. That's why VNC over X looks so fast.

The top things I would like to see:
1.) Sound implemented (this would make UltraVNC light years ahead of everyone else!)

What for? Please try to justify.

2.) More Enterprise Level features (i.e. like VNCon even if it would need to be done in a side project)

Sounds fine.

I would actually like something as automatic or very easy deployement of UVNC in large scale server/client environments - not just watching them, but deploying them. This would make it so attractive that companies could not withstand this product ... first thing we need for this is a bundled driver.

Then redge's proposals (except for sound ) sound interesting.

[Rudi De Vos]

Code description (sample)

Screen_changes_class


+Receive screen changes
+Filter updates

The screen changes class is responsible for receiving the content of the
hookdll or ringbuffer. Together with the gdi info the output is an optimal
list of moves and an update region.
The class is called each time a new update is requested.

Receive_screen_changes is a seperated thread, that continues update
a change region and list of moves. The thread is locked during filter access.

Filter_updates is responsible for generating an optimal list of moves and regions.
+combining moves A->B->C->D...... we only want A->D
moves can be clipped so A can be 3 seperate rectangles and size of rectangle can differ every position ????
+gdi move info already give A-D, but does not clip
+every move need to be recheck (region) next run
+current moves need to be subtracted from current region
+to many small regions need to be optimal combined to prevent to much protocol overhead and bad compression ratio

...

If we want to work with more people, we realy need some functional description+flow
So someone can attack the "filer_updates" with little influence on the other code.
Only prob.....this is a lot of work.

[Oliver]

Only prob.....this is a lot of work.

... split to be done by several people

[californiajeff]

First off, no matter what we must never ever break compatibility. That would be the kiss of death!

I partially disagree. Why? Well, first of all we are thinking to change the codebase and back/foreporting can be much more tedious than coding from scratch.

Second, if you talk of compatibility with the VNC protocol, I believe this is no question. This will be maintained. You will be able to watch it from either a standard VNC viewer or the one which comes with UVNC.

As far as compatibility goes, we need to maintain viewer compatibility no matter what. As for the bonus features like sound etc. I am not expecting them to be compatible across all viewers.

The top things I would like to see:
1.) Sound implemented (this would make UltraVNC light years ahead of everyone else!)

What for? Please try to justify.

What for you ask? Well why not? It seems like a rhetorical question if you ask me. I was under the impression sound was always on the drawing board for a 2.0 release. Why not have audio control in addition to video control? I could then control audio stuff on remote computers and even hear alerts. Probably a toggle button should be programmed to turn this feature on and off. I am not sure how much extra bandwidth it would require.

After all, if you are so against audio support why even have video support. Why don't we just control everything from the command line like we did a long time ago. Sorry, if I got a little carried away on that.

2.) More Enterprise Level features (i.e. like VNCon even if it would need to be done in a side project)

Sounds fine.

I would actually like something as automatic or very easy deployement of UVNC in large scale server/client environments - not just watching them, but deploying them. This would make it so attractive that companies could not withstand this product ... first thing we need for this is a bundled driver.

I agree on that. I would also like printer support like someone else suggested. Although, I don't how we would implement that. How would windows know to print to a printer that's on my desktop through VNC? We may encounter some OS limitations there... Just a thought.

[californiajeff]

Okay, let me summarize from the chat:

• modular design of the codebase (no matter whether RVNC 3 or 4)
  This includes to split the project into parts which can be split easily.
• Open the team (CVS direct access) to more cool developpers (Oliver, Marsha, lizard... ?) (Sam speaking )

I have not done any programming on the project but I think a modular design of the codebase is an excellent idea and it should probably be our top priority. I think this will make it much easier for the project to add more people and to move into more directions into the future.

Also, I am just guessing here but would creating a modular codebase make it easier to add in future features like sound, printing, etc.?

One last suggestion on the modular codebase, I think it should be done as a side project like Mozilla did with Firefox. How about UltraVNC Starlight for the name? (just trying to think up something creative) Then when it's complete maybe bring it back over as UltraVNC and call it version 2.0. What do you think?

Then after that is done and it is stable we could work on all those extra features...

[Oliver]

As far as compatibility goes, we need to maintain viewer compatibility no matter what. As for the bonus features like sound etc. I am not expecting them to be compatible across all viewers.

Okay then. I believe this was always planned. But when it comes to compatibility a developer also thinks of the driver and other things!

What for you ask? Well why not? It seems like a rhetorical question if you ask me.

It was serious. Because I personally cannot imagine any use for it (, yet).

I was under the impression sound was always on the drawing board for a 2.0 release. Why not have audio control in addition to video control? I could then control audio stuff on remote computers and even hear alerts. Probably a toggle button should be programmed to turn this feature on and off. I am not sure how much extra bandwidth it would require.

Depends on the quality. But as well as for the printer support you mention this will be very limited (not X-OS, I guess, and much much more limitations).

After all, if you are so against audio support why even have video support.

Because that is why you write a remote control program
If you can get Windows better administrated via commandline - do it ... I know I can't from my experience as a network admin in an NT server/client environment. It's just too limited.

I agree on that. I would also like printer support like someone else suggested. Although, I don't how we would implement that. How would windows know to print to a printer that's on my desktop through VNC? We may encounter some OS limitations there... Just a thought.

Printer support sounds nice but may be hard to implement. There is no single standard how you transfer something to the printer, but when it comes to display devices you can be sure that every pixel has a certain number of bits and so on (if you intercept it "directly before" output). This is missing for printers (different printer languages different APIs, GDI, PostScript, ...). Redirection on Windows, however, may be possible and even feasible for the team somewhen in future.

I have not done any programming on the project but I think a modular design of the codebase is an excellent idea and it should probably be our top priority. I think this will make it much easier for the project to add more people and to move into more directions into the future.

I personally would prefer a compact binary - if the programming itself is being split up I don't care that much. But a single binary should contain all what's needed to run UVNC.

Also, I am just guessing here but would creating a modular codebase make it easier to add in future features like sound, printing, etc.?

Depends really *how* you split it up. From what Rudi said it sounds promising.

One last suggestion on the modular codebase, I think it should be done as a side project like Mozilla did with Firefox. How about UltraVNC Starlight for the name? (just trying to think up something creative) Then when it's complete maybe bring it back over as UltraVNC and call it version 2.0. What do you think?

Why would you do this (serious question!). In the CVS it will be most likely just a branch?!

[redge]

Then redge's proposals (except for sound Very Happy ) sound interesting.

RTP (Real Time Protocol) known good for real time voice too)

Because that is why you write a remote control program

I understand your point of view in strict way of remote control
Remember remote support/helper is human, not robot (or any script)t need speaking other than deaf person (sorry)

another example:
There 2 partners have a microphone,
why not use the current session power usage of RTP that made fot that real time audio transport ?
not only strict remote control, that easy to disable microphone and save precious bandwith.

workaround:
use classic POTS/ISDN telephone or SIP telephone over IP for speak with remote user.


FAQ RTP
http://www.cs.columbia.edu/~hgs/rtp/faq.html

[californiajeff]

One last suggestion on the modular codebase, I think it should be done as a side project like Mozilla did with Firefox. How about UltraVNC Starlight for the name? (just trying to think up something creative) Then when it's complete maybe bring it back over as UltraVNC and call it version 2.0. What do you think?

Why would you do this (serious question!). In the CVS it will be most likely just a branch?!

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.

[redge]

add Unicode as base of UltraVNC 2 code support.

add NVC inside the vncviewer
add SVC inside the winvnc

that really more international and more friendly NAT router passtrough.

nice holidays and be happy

[Rudi De Vos]

Beta2
+The startup will be very slow.
Just some paper design will already take a few months.
+Beta2 will start in his own cvs root.
+Rel1.00 keeps his own proper cvs, so we still can make bug fixes
and some minor changes

We have no intention to stop Rel1.00 development, but work on Beta2 and Rel1.00 until Beta2 has become mature.

Beta2 will take a year...i don't now.

[red]

I would actually like something as automatic or very easy deployement of UVNC in large scale server/client environments - not just watching them, but deploying them. This would make it so attractive that companies could not withstand this product

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.

red