Re: [gtk-vnc-devel] disconnect signal

[Anthony Liguori <anthony codemonkey ws>]

Daniel P. Berrange wrote:
> On Thu, Sep 13, 2007 at 10:47:21AM -0500, Anthony Liguori wrote:
>   
> > >   
> > >       
> > > > One thing I do want to add though is a 'error' signal which would be emitted
> > > > whenever anything goes wrong in the client (ie anywhere the code which sets
> > > > the has_error flag to TRUE). In particular this signal would include some
> > > > kind of info about what failed - perhaps just the 'strerror(errno)' data or
> > > > a message generated by our own code for some semantic error eg "Unsupported
> > > > protocol version", or "Supported authentiction method", or 'Remote server
> > > > closed connection". Would a general 'error' signal solve the issue you want
> > > > to address ?  The 'error' signal would of course be immediately followed by
> > > > the 'disconnected' signal too. 
> > > >
> > > > Dan.
> > > >     
> > > >         
> > > Indeed again, but, in this case, the 'disconnected' signal is useless in
> > > my opinion.
> > >   
> > >       
> > I agree with Dan.  I think simpler semantics is always better.  
> > Disconnected doesn't necessarily mean error.
> >
> >     
> > > I was about to ask for a 'auth error' signal, but this 'error' signal is
> > > more generic and i think it solves my problems.
> > >   
> > >       
> > I don't much like the idea of an "error" signal.  It means that you end 
> > up with a catch-all handler.
> >
> > You definitely want a separate authentication-error signal.  For the 
> > case where the server prematurely closes the connection, and 
> > unexpected-end-of-file signal or something similar would be useful.  
> > Note that an unexpected EOF is not the same as disconnected.
> >     
>
> I looked at this and there is not currently any easy way to distinguish
> between a regular shutdown (from vnc_display_close/gvnc_close) and an
> unplanned shutdown (remote server closes / protocol error), so I've not
> addressed this. 
>   

Yeah, the it would require some refactoring.

> The attached patch does however add a 'vnc-auth-failure' signal so you
> can explicitly handle that common scenario. It also adds a vnc-desktop-resize
> signal that Gerd previously requested.
>
> So as not to delay the release further I'd say we go with this for now and
> I'll investigate if there's a way to add separate useful signals for detecting
> more interesting shutdown / error conditions.
>   

Sounds good to me.

Regards,

Anthony Liguori

> Dan.
>