[BRLTTY] make drivers a library?
Nicolas Pitre
nico at fluxnic.net
Tue Sep 22 20:15:31 EDT 2009
On Wed, 23 Sep 2009, Samuel Thibault wrote:
> Nicolas Pitre, le Tue 22 Sep 2009 17:28:38 -0400, a écrit :
> > > Now, another issue is "portability" in windows terms: users want to be
> > > able to throw nvda+brltty on a USB key and easily start them on any
> > > computer after just plugging the key in. Yes, they could just start
> > > brltty and then NVDA, but apparently it's still some blocker for casual
> > > users. NVDA could start BRLTTY itself, of course, but James is reluctant
> > > to do that due to the potential issues it could bring.
> >
> > Hence my assertion that BrlAPI should be the agent taking care of that.
>
> And assume that if BRLTTY is not already installed on the hard drive it
> should start the brltty.exe lying around?
What do you mean by "not installed" if there is a brltty.exe lying
around?
If BRLTTY is not installed then there isn't much the human user nor
BrlAPI can do about it, no?
> > > > Should be possible to configure compilation of BRLTTY+BrlAPI to
> > > > achieve just that without having to write interface code.
> > >
> > > You mean by using something like a pipe inside the process itself, on
> > > which the BrlAPI protocol will flow?
> >
> > Exact!
>
> Wow, if Frans J. Pop was hearing you he would surely have a heart
> attack, as it's a particularly not optimized solution for embedded
> environments. You could even not have threads available...
Well... My Linux kernel can be configured down to a 400 KB binary (no
networking, no block devices) or up to a 20 MB blob (with everything
possible conpiled in). Same source base, with the former result
certainly suited to some embedded applications while the later makes
sense for testing on big machines only. BRLTTY itself is still
configurable like that, although to a lesser extent. I'm sure BrlAPI
could follow the same model, from the static and single threaded and
single instance model up to the current multi client with independent
daemon model. It's the resulting compiled binary that matters, not the
source tree it comes from.
Nicolas
More information about the BRLTTY
mailing list