Hi, On Tue, Jun 21, 2011 at 09:14:30AM -0700, Alan Coopersmith wrote: > On 06/21/11 02:52 AM, Daniel Stone wrote: > > On Mon, Jun 20, 2011 at 06:50:47PM -0400, Adam Jackson wrote: > >> The caveat here is that unused data in errors isn't guaranteed to be > >> 0, which means you'd have to know to only look for extra BadMatch > >> info for either a particular server version or (better) protocol > >> version. You could reasonably make that part of protocol 11.1, on > >> the assumption that 11.0 clients wouldn't bother looking for it, but > >> that 11.1 clients would want to be assured of it. > > > > Yeah, I was thinking about protocol 11.1, but from > > ProcEstablishConnection: > > [...] > > > > So we could bump the server to 11.1 and allow 11.0 clients to connect, > > but 11.1 clients wouldn't be able to declare that to 11.0 servers. Ugh. > > Would it be simpler then to do this via an extension? Perhaps Generic Event > 1.1 > could return more detailed errors to clients registered with it? > > Seems like it would be nice to not just return the bad value in the error, but > some hint as to which field it was when multiple fields may contain the same > values.
Mm, we'd then need to define GE equivalents for all core errors, and somehow make clients aware of them. I think I'm more or less with ajax that we should do it in a core protocol rev, otherwise it's probably not worth bothering with tbqh. Julien also pointed out for the client-connection issue, that if clients are having to retry on failing r/R vs. l/B anyway, 11.1 clients could just try reconnecting with 11.0 if they fail connection to a 11.0 server. Cheers, Daniel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
