On Thu, Nov 11, 2010 at 03:42:39PM +0100, Adam Tkac wrote: > > 6. Implment TLS security type > > 7. Implement X509 Security types > > Just a design question. Wouldn't be better to merge TLSTunnel, > TLSTunnelBase and X509Tunnel classes to the one class as I did it in > common/rfb/CSecurityTLS.*? In my opinion X509 and TLS classes contain > nearly same code so it will be nice to have it in the one class (and > constructor will take boolean parameter which will select between > anonymous/X.509 TLS).
I had these classes sitting in one of my development trees for some time, so I just was lazy and copied them 1:1. Feel free to merge them, if you think its better - I can live with both solutions. Personally, I would probably still prefere the split classes. In the java case, a useful X509 is probably bigger (1:2 - all certificate checking is still missing). > > 8. Disable TightVNC security type > > I will disable TightVNC type in the Java client later. > > > 9. Remove TightVNC security type from server > > 10. Remove Tightvnc Security type from java client > > Not sure about those two patches, yet. I still think, its the best to let the tightvnc security type die. It provides no benefit for tigervnc and is little used (and therefore tested) code. The other option would require: * add VeNCrypt as tightvnc authentification type and * add support for tightvnc authentification to the C client Regards, Martin Kögler ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
