Re: More from me...

  • From: sholden@xxxxxxxxxxxxxx
  • To: wilyfans@xxxxxxxxxxxxx
  • Date: Fri, 16 Jul 2004 14:21:10 +1000

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



Other related posts: