[BRLTTY] make drivers a library?

[Nicolas Pitre]

On Tue, 22 Sep 2009, Samuel Thibault wrote:

> Nicolas Pitre, le Tue 22 Sep 2009 16:59:23 -0400, a écrit :
> > 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?
> 
> For a casual user, it is.

I think I'm not making myself understood.

For a _human»_ user having to manually start BRLTTY beforehand is 
stupid.

Ideally, NVDA should take care of starting/stopping BRLTTY itself.

An even better solution would consist of BrlAPI taking care of 
starting/stopping BRLTTY as needed instead, so that knowledge is 
localized and shielded from BrlAPI users.

> > > 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.
> 
> This is _already_ what happens. When no BrlAPI client is connected,
> BRLTTY doesn't take control of the braille device. When a windows
> command line is opened, however, BRLTTY acts as a reader for it. A
> solution could be to disable command line screen reading completely by
> default.  Not a good thing for people using it as a command line screen
> reader, but maybe we can consider that those are able to re-enable it.
> 
> 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 a braille library won't solve anything either.
> 
> Indeed, but it will makes things simpler to deal for the user: two
> applications using the same device. Close one, run the other, or
> vice-versa. And not a service to start/stop. Yes, considering that when
> NVDA is stopped BRLTTY shouldn't harm, it shouldn't be a problem but I
> still see reluctancy from windows users.

See above.

> > 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!  For small environment you configure BrlAPI+BRLTTY like that, 
which effectively becomes a library.  For other environment with 
concurrent "clients" you configure BrlAPI+BRLTTY in a client/server 
model.  In both cases the same API is used and the clients don't need to 
make a difference.


Nicolas