Path: utzoo!attcan!uunet!husc6!bloom-beacon!EXPO.LCS.MIT.EDU!jim
From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: Re: Request for Object-Oriented extension to XEvents (long)
Message-ID: <8810181510.AA25050@EXPO.LCS.MIT.EDU>
Date: 18 Oct 88 15:10:25 GMT
References: <161@tityus.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 93


Okay, I'll play devil's advocate:


>     Before making this request, I want to state that I understand
>     the  current  pressure  upon  the MIT staff to get R3 out and
>     free of problems as quickly as possible.

Glad to hear it.  :-)


>                                              The request  that  I
>     am making is assumed NOT to be part of the next release of X,

Actually, the constraints on the MIT staff have almost nothing to do with
whether or not something is added to the core protocol and libraries.  All such
extensions (especially ones that possibly involve incompatible changes to the
protocol) must go through the Consortium before they even come close to the
tape.


>     This lookup is currently within the server, to determine  the
>     XID  of  the  event  being  dispatched, as well as within the
>     client, to map the XID to the client data internals. It would
>     be  nice  to eliminate the redundancy from the client side of
>     the logic.

It seems that all you'd be saving would be a hash table lookup.


>                           The pointer would be a generic "UserDa-
>     ta" field, and it was up to the client to define  and  inter-
>     pret  this  field.  In  an  object-oriented world the pointer
>     would point to the object of the window, whatever data format
>     that was defined as being.

It would be an "arbitrary data" field, not a "pointer" (What are pointers
anyway?  And, how much space do you need to hold one?  Hint: the answer isn't
"32 bits"!).  You'd probably want to have it obey the same swapping rules as
properties.  But, whether or not an application would choose to be unportable
and store a real pointer in it depends on the semantics of setting the user
data field. 

For example, is there a user data field for every client for every window?  If
not, what do you do when more than one application wants to stick something on
the window?  Does the last request (which is what, by the way: extend the core
ChangeWindowAttributes or add a new request?) to change it win?  Unfortunately,
this means that multiple applications trying to set user data on a single
window will get horribly confused (better not store store actual pointers in
there...). 

Okay, so you could add a new UserDataChange event and either extend one of the
existing event masks or add a new UserDataMask.  Then, applications could get
an event whenever the user data whenever the user data field gets changed, so
that they can decide whether or not to pitch their cookies. 

But, this means that applications can't absolutely rely on the user data.
Instead, they would have to treat the data as a hint to optimize lookup, but
they would still need to have a hash table.

Now, suspending belief for a second, perhaps we could add a GrabUserData
request or another field which indicates whether or not the data field has been
set.  But, we now get into race conditions, timestamps, and other nastiness.
Yuck.  For something that started out trying to save applications a little bit
of work, we're getting kind of hairy. 


>     This capability would eliminate the need for additional logic
>     and   overhead  of  the  client  process.

But, by how much?  You could well end up with more complexity than the 
simple hash table with a tiny cache.


> Thanks for listening to yet another request.

Being a forum for discussing new ideas is one of XPERT's primary goals.


>                                              I hope this one  can
> make it in at some time, I think it would greatly help in the fu-
> ture speed and complexity of X products.

In order for that to happen, somebody would need to generate a detailed
proposal.  If you are interested in pursuing this sort of extension, you will
need to spend some time writing down exactly what the semantics are, what new
requests, events, attributes, etc. would be necessary, and how it could be done
so that existing clients would work with a new server without having to be
relinked.  


						Jim Fulton
						MIT X Consortium