This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] New package: brltty 3.8

On Thu, Jun 07, 2007 at 07:49:50PM +0800, Samuel Thibault wrote:
>Christopher Faylor, le Wed 06 Jun 2007 16:11:11 -0400, a ?crit :
>> On Thu, Jun 07, 2007 at 03:24:45AM +0800, Samuel Thibault wrote:
>> >Brian Dessent, le Wed 06 Jun 2007 02:42:50 -0700, a ?crit :
>> >> Yes, setup automatically selects everything in Base for installation,
>> >
>> >Ah, I didn't know that, is that documented somewhere??
>> Yes:
>Mmm, maybe a short note in would be useful?


>> >That would make programming less easy.  Brltty can communicate with
>> >other (potentially non-cygwin) applications with tcp/ip (remotely) or
>> >local pipes (locally, more efficiently).  For keeping compatibility
>> >with other applications for local pipes, windows pipes are used.
>> >Mixing cygwin sockets and windows local pipes is not particularly fun,
>> >so that's why we end up just using windows socket and
>> >WaitForMultipleObjects() in a separate thread.
>> You haven't really described why the linux-like pipe() command is
>> inadequate for anything that an application needs.
>This application needs to communicate about accessibility with
>non-cygwin applications too.  Does the linux-like pipe() map 1-1 to
>windows pipes?
>> Merely stating that "mixing cygwin sockets and windows local pipes is
>> not... fun" is not really an argument for not doing it.
>This was an euphemism for "using select is already tricky, mixing both
>a select() for cygwin sockets and WaitForMultipleObjects() for windows
>named pipes, and handle the different kinds of sockets, that would be a
>Really, for the sake of maintainability, this is a lot simpler.

You're just restating things as if everyone knows what you're talking

You're now mentioning named pipes which adds another data point but if
brltty is working on linux then I don't see why it can't be using
linux-like techniques on cygwin, cygwin bugs notwithstanding.  You don't
appear to be saying that you've stumbled over a cygwin bug.  Instead you
just keep saying that it's hard to mix windows and cygwin things.  Well,
duh.  Just don't use the Windows things.

>> Unless there is good reason, the cygwin distribution really is
>> supposed to be comprised of programs which use the linux API.
>But when talking about communicating with other applications, we need to
>use windows interfaces when the linux API doesn't permit it, shouldn't

Only if you can clearly communicate why the linux API doesn't work.  I'm
not convinced that this is not just a misconception on your part.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]