[BRLTTY] make drivers a library?

[Nicolas Pitre]

On Tue, 22 Sep 2009, Samuel Thibault wrote:

> Nicolas Pitre, le Tue 22 Sep 2009 13:32:40 -0400, a écrit :
> > On Tue, 22 Sep 2009, Samuel Thibault wrote:
> > > Yet another person on the NVDA list wanted to re-implement a driver for
> > > some braille device because he doesn't want to have to run both brltty
> > > and nvda at the same time.
> 
> Various reasons such as additionally mentioned in my other post
> http://mielke.cc/pipermail/brltty/2009-September/006118.html
> having to deal with starting/stopping two daemons at a time.

You're kidding or what?  Or maybe Windows is such a strange environment 
that starting/stopping daemons is such a big deal?

> > > Of course, it's a better thing to use the brlapi facility as this
> > > permits to run several readers, dedicated applications, etc. but for
> > > the casual user this seems superfluous considering the difficulty of
> > > installing both brltty and nvda (yes, I believe we got to a very simple
> > > way to achieve that, but two applications is still too much for casual
> > > users).
> > 
> > I don't buy that for a minute.  Windows has plenty of installer kits to 
> > chose from, making all the underlying 
> > programs/services/components/whatnot bundled and installed together with 
> > no distinction unless the user really wants to dig.  Most games will 
> > package DirectX and install it unless there is already a newer version 
> > installed already for example.
> 
> Yes, but they don't start a service that may completely steal the screen
> output and interfere with the VGA driver just because one has opened a
> command line window, which is equivalent to what currently happens after
> having installed brltty while jaws is installed.

This is of course a bug with BRLTTY.  One shouldn't have to relinquish 
the screen output because BRLTTY is starting only to serve BrlAPI 
requests.

In fact, I'm actually thinking that any BrlAPI user shouldn't have to 
deal with starting BRLTTY at all.  Instead, it should be BrlAPI's 
responsibility to start/stop BRLTTY itself as needed and shield the 
necessary mechanic from BrlAPI users.  This way you have a single API 
and behind the scene it could well be possible for BrlAPI to actually be 
linked with BRLTTY without having a separate process, or be a separate 
process with a communication pipe, etc.  In any case it is a bit silly 
for BrlAPI users to have to know how and when to start (or not start) 
BRLTTY.

> > Also, if NVDA relies on BRLTTY to work properly then it should ensure 
> > BRLTTY is running and start it otherwise, all by itself.  This is not 
> > rocket science.
> 
> Ok, and when shutting down NVDA, should it shut down BRLTTY?

Sure!  But it shouldn't care -- see above.

> What if it
> just happened that NVDA got started before the proper script that was
> supposed to start BRLTTY once for good got a chance to run?

Then maybe BRLTTY should be smart enough to realize there is another 
instance already running and connect to it possibly as an additional 
BrlAPI user.  In fact, on Windows with many contenders for the braille 
display, maybe BRLTTY should only provide the core BrlAPI service and 
the traditional text screen translation to braille should always be made 
into a BrlAPI client of its own.

> > > As a result, I yet more and more believe that brltty should export its
> > > drivers through a library too, even with an simple interface similar
> > > to libbrlapi/libbraille.
> > 
> > Are they thinking the same about the Windows speech API?
> 
> The windows speech API doesn't pose access to sound card issues and
> interference with jaws & co like access to braille devices do.

And a braille library won't solve anything either.  If the braille 
display is used by one program, it won't be available for another.  The 
first to grab it wins, or the second one just bullies its way through 
and make a mess. So I don't see how a library would avoid the kind of 
interferences you're referring to above.  At least BrlAPI could play a 
central role and arbitrate access to the braille display, maintain a 
client use count and release the device and/or shutdown when the count 
goes to zero, etc.  This is how Windows (or PulseAudio) is using the 
sound hardware, except that sound is mixed together, which is not 
possible with a braille display of course.

> > > Else I fear dispersion of hardware support
> > > efforts.
> > 
> > If the effort needed to make proper integration of BRLTTY/BRLAPI for a 
> > better NVDA user experience is greater than plain driver duplication, 
> > then I'm afraid that making a proper library interface would be an even 
> > greater effort (except that the effort is now shifted to BRLTTY 
> > developers instead).
> 
> I'd rather see better integration too, but up to now that hasn't been
> a success, while I can see how BRLTTY could manage to externalise its
> drivers,

It already does.

> and as I said in the other post it could be useful for other
> cases too like grub or other kind of embedding on small devices which
> can't afford local sockets and threads just for BrlAPI.

That is perhaps the most valuable argument for libification.  But again 
I'd simply use the BrlAPI interface with the inter-process communication 
layer removed instead of having yet another API.  Should be possible to 
configure compilation of BRLTTY+BrlAPI to achieve just that without 
having to write interface code.

> > > What do people think?
> > 
> > I think this is the wrong solution for a valid issue.
> 
> Usual answer from you :)

What did you expect?  ;-)


Nicolas