[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