Re: Thoughts for discussion & info request (fwd)

Here's the note Joerg asked me to forward:

Wittenberger wrote:
> From irz301.inf.tu-dresden.de!ibch50.inf.tu-dresden.de!jw Tue Aug 16 13:30:14 1994
> Date: Tue, 16 Aug 1994 12:58:11 +0200
> From: Wittenberger <jw@ibch50.inf.tu-dresden.de>
> Message-Id: <9408161058.AA18251@ibch50.inf.tu-dresden.de>
> To: dave@humbug.demon.co.uk
> In-Reply-To: <m0qZwJB-00041zC@humbug.demon.co.uk> (message from Dave Hudson on Mon, 15 Aug 1994 08:18:13 +0100 (BST))
> Subject: Re: Thoughts for discussion & info request
>
>
> > Well, after I did some work on the serial and ps/2 mouse code a couple of
> > months back I think the server handles both 2 and 3 button mice
> > automatically (it's possible on these 2 types to handle 2 button mice as a
> > subset of 3 button mice).
>
> I think you didn't get what I'm talking about. It is not the problem
> that you might have 2 and 3 button at the same time. It's a matter of
> evolution. When you had only 2 button you can only write code for 2
> button. Period. It's just because you can't know that anybody will
> ever invent the 3rd button. When the 3rd button is added later you run
> into the typical problem of needing an update. But with the ability of
> renaming and aliasing its just a little extention which never affects
> anything else.
>
> (Over all, the problem with the mouse is just a example, and because
> of the fact, that the 3rd button of the mouse is older than VSTa it is
> no real problem with VSTa. But which example should I chose about
> things not invented yet?)
>
> >
> > As for the problem with what we call them, I can see two easy ways to
> > implement this:
> >
> > 1) We could simply call the mouse srv/mouse (as we do now) and use the
> > FS_WSTAT mechanism to allow the client to specify the mode of operation. As
> > an example we could define "btnemu" which could take an number of arbitrary
> > states, say "none", "both_pressed_equals_middle" or "keyboard_key_m". It's
> > an exagerated example, but I think it gives the general idea.
>
> And now the old code would never work, because it dosn't know about
> the new extention of FS_WSTAT.
>
> Or the old behavior is default, then the new code is filled up with
> unneccessary code for changing the mode. Code which doen't belong to
> the work it really should do.
>
> >
> > 2) We could make the mouse server provide a subdirectory of possible server
> > variants - whichever one is opened by the client would then define the
> > server's behaviour, say:
> >
> > srv/mouse:2btn
> > srv/mouse:3btn
> > srv/mouse:2emu3btn
> >
>
> Yes, but the same problem applies. You have to comlete update the
> server.
>
> > When we mount the server into our namespace we can mount either the whole
> > server namespace and have say:
> >
> > /dev/mouse/2btn
> > /dev/mouse/3btn
> > /dev/mouse/2emu3btn
> >
> > or we could mount the individual server variant we require and just call it
> > /dev/mouse.
> >
>
> That is what I'd like. But why mut we be forced to have the services
> come from only one server?
>
> > In this instance I'd have a personal leaning towards solution 1, but there's
>
> I think it is because it is the custom, traditional way.
>
> > no good reason that I can point at for this, as with the modified fd server
> > I've used the second approach to allow the user to specify the media type
> > in the drive. It's exactly this sort of flexibility in server coding that
> > makes me prefer VSTa to say Unix (although it did take me a couple of months
> > to appreciate the benefits).
>
> I agree. But the question again, why should we get the benefit from
> the flexibility after the definiton of the server but not before?
>
> Regards
> Joerg.
>
>
Received on Tue Aug 16 05:55:36 1994