Gary Capell writes: >On Thu, Jul 15, 2004 at 11:57:28PM +1000, Sam Holden wrote: >> Damn you gary for sending an initial WEConnected message at >> connection time so I could do backward compatible >> versioning... :) I missed a 'not' somewhere there... > >"Never attribute to malice that which can be adequately explained by >stupidity." >Hanlon's Razor. Damn your malicious stupidity! Anyway... more talking to myself - feel free to tell me to shut up or criticise something. I'm not certain binary compatability with the message protocol matters much, because: 1. There aren't many users of wily (compared with say emacs) 2. Even fewer have used the message interface 3. Fewer still wouldn't be able to recompile such programs However, it's traditional to maintain backwards compatibility, so I thought about. The existing system is reasonable, and everything I want is additional which makes it backward compatibility possible after all... So my solution is to add WMgetfeatures and WRgetfeatures message types as 33 and 34. No existing client will be sending an message of type 33 (currently WMfencepost) unless they wanted a WRerror response for some strange reason. So a client can simply send a message of type WMgetfeatures==33 and if it gets back a WRerror then it knows it has connected to a standard wily (and I hereby set the current implementation as "standard"). If it gets back a WRgetfeatures==34 then it can examine the string in the message to get a list of whitespace seperated feature names. Feature names will need to be "standardised", but if it was possibly for Befunge to do so, it can't be hard for wily. I suggest a process somewhat simpler than ISO standards. And another "Damn you" to gary: There is *zero* space left for new events, you couldn't have used the lower byte for events and the upper for requests and responses or something could you.... So WEselect can't be added (after all you can attach for b3 stuff with WEgoto, b2 stuff with WEexec, but you can't tell when a user sweeped some text with b1 - that I know of anyway)... I would also like to propose an initial extension, which would allow more flexible attaching to events. WMdetach (and WRdetach) would be defined and would detach from the events specified in the flag. WMattach would be changed to union the current events received with those in the flag... I've implemented the getfeatures messages in wily, if anyone cares. Mmmm... I really have to write that tech report now. -- Sam