Roland McGrath <[EMAIL PROTECTED]> writes:
> > It's a lot easier on everything, I think.
>
> I think you are wrong.
>
> > The client can just open the file, and then hand the handle over to
> > the server.
>
> Which means that if the client wants to supply data from someplace else, it
> has
On Mon, Mar 11, 2002 at 11:27:23PM -0800, Thomas Bushnell, BSG wrote:
> Roland McGrath <[EMAIL PROTECTED]> writes:
>
> > > An alternative strategy (for the dynamic case) is to have the client
> > > hand a port for the file to the console server, which can then read
> > > from it exactly as if it
> It's a lot easier on everything, I think.
I think you are wrong.
> The client can just open the file, and then hand the handle over to
> the server.
Which means that if the client wants to supply data from someplace else, it
has to become a filesystem.
> The server can just read it exactly
Roland McGrath <[EMAIL PROTECTED]> writes:
> > An alternative strategy (for the dynamic case) is to have the client
> > hand a port for the file to the console server, which can then read
> > from it exactly as if it were a file (which it normally will be).
>
> Yeah, maybe. But that is certainl
> An alternative strategy (for the dynamic case) is to have the client
> hand a port for the file to the console server, which can then read
> from it exactly as if it were a file (which it normally will be).
Yeah, maybe. But that is certainly more of a burden on the server to stay
robust that j
Roland McGrath <[EMAIL PROTECTED]> writes:
> > And then the way to change that dynamically is to, well, do a setopts
> > call.
> >
> > If there is some error and it can't read the file, then it returns an
> > error and leaves the previous keymap in place.
>
> That seem utterly unacceptable to m
> And then the way to change that dynamically is to, well, do a setopts
> call.
>
> If there is some error and it can't read the file, then it returns an
> error and leaves the previous keymap in place.
That seem utterly unacceptable to me based on the principles I described.
Since you haven't r
Roland McGrath <[EMAIL PROTECTED]> writes:
> That second condition really means not presuming that there is any common
> filesystem at all between the user and the server, so the shared temporary
> file concept does not fit.
It seems to me that the ideal thing would have the passive translator
h
> Maybe I don't know enough about the xfs protocol.
Me either.
> But it seems to me a very good thing if the console server can copletely
> configure itself from the passive translator setting, without requiring
> to run a loadfont program or anything.
I certainly agree with that. And having
On Mon, Mar 11, 2002 at 04:51:03AM -0500, Roland McGrath wrote:
> That is a wacky notion, but it might just make sense. Certainly using the
> xkb utilities from X directly is an attractive idea. Not only is the
> configuration based on a compatible format, it's actually the very same
> commands
How are you handling keyboard LEDs?
> Mmmh. You know, I considered supporting a subset of the X server protocol
> for that, so that you can use an X font server which supplies the fonts to
> the console server, and xkb to configure your keyboard map. That will
> definitely not be done in the
On Sun, Mar 10, 2002 at 07:47:23PM -0500, Roland McGrath wrote:
> If you wanted to do that, you could call another argp's parse_opt function
> from yours via the children pointers.
Ok.
> As to your particular option syntax plans for console, I can't even figure
> out what most of that means exac
12 matches
Mail list logo
