Alan Coopersmith wrote:
> Darren J Moffat wrote:
>> Alan Coopersmith wrote:
>>> I am sponsoring this case for myself and the Vino project team.
>>> I have marked it closed approved automatic - speak up soon if you object!
>>> This case requests a patch release binding.
>> I don't think this meets automatic approval, I'd prefer to see it run as
>> a fast-track.
> 
> Okay, timer set for one week from submission, November 7.
> 
>> This case introduces a second vncviewer client, why do we need this one
>> and Vino ?  Why should this one and not Vino be /usr/bin/vncviewer ?
> 
> This case supersedes the one in which Vino delivered the simple shell script
> wrapper around the Java applet Vino provides for users to download over http
> from another computer, so Solaris/OpenSolaris will only have one vncviewer
> at a time.

Huh ?  That still makes two to me, one which is native code and one 
which is a jar file.  It that is what vino is supposed to be then I 
think I'm fine with having both they seem to serve different purposes as 
implementations of the same protocol.

>> I also don't think Volatile as the only classification for a vncviewer
>> is acceptable - particularly given that it is a core component of how
>> xVM is used and tools like virt-install(1M) need to call it.
> 
> I had no idea virt-install called it - there was no objection to Vino's
> vncviewer script being Volatile with no documentation of the arguments in
> the previous case, and no contracts listed in that case for anyone to
> depend on the vncviewer interfaces.

That's because I didn't see the previous case!  Nor did I know until 
this week that Vino is currently called in virt-install but so could 
vncviewer be as well (I think the need for vino modifications go away 
with this case though).

Does this vncviewer support SSL/TLS ?  If so which SSL/TLS library does 
it use.

-- 
Darren J Moffat

Reply via email to