2009/3/5 Luke Kenneth Casson Leighton :
> On Thu, Mar 5, 2009 at 3:06 AM, Ben Klein wrote:
>> 2009/3/5 Luke Kenneth Casson Leighton :
>>> On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard
>>> wrote:
Luke Kenneth Casson Leighton writes:
> i would imagine that inefficient is the _
On Wed, Mar 4, 2009 at 10:14 PM, Alexandre Julliard wrote:
> Luke Kenneth Casson Leighton writes:
>
how would you envisage doing client-side SMB named pipes?
>>>
>>> By doing the I/O through the wineserver. It has all the necessary
>>> mechanisms already.
>>
>> ok - great. whereabouts? whi
>> sure you can. by redesigning.
>>
>>
>>
> Since I deal with that on a daily basis, I'll step in. A great design
> is one that does EVERYTHING right the first time.
have you heard of incremental improvements?
> What you are
> proposing goes counter to this and is unacceptable.
have you hea
On Thu, Mar 5, 2009 at 3:06 AM, Ben Klein wrote:
> 2009/3/5 Luke Kenneth Casson Leighton :
>> On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard
>> wrote:
>>> Luke Kenneth Casson Leighton writes:
>>>
i would imagine that inefficient is the _last_ thing on the list of
priorities. "te
Luke Kenneth Casson Leighton wrote:
> On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard
> wrote:
>
>> Luke Kenneth Casson Leighton writes:
>>
>>
>>> i would imagine that inefficient is the _last_ thing on the list of
>>> priorities. "technically correctly fulfilling the semantics" i w
2009/3/5 Luke Kenneth Casson Leighton :
> On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard
> wrote:
>> Luke Kenneth Casson Leighton writes:
>>
>>> i would imagine that inefficient is the _last_ thing on the list of
>>> priorities. "technically correctly fulfilling the semantics" i would
>>>
Luke Kenneth Casson Leighton writes:
>>> how would you envisage doing client-side SMB named pipes?
>>
>> By doing the I/O through the wineserver. It has all the necessary
>> mechanisms already.
>
> ok - great. whereabouts? which ones? any existing examples? which
> existing code in wineserver u
On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard wrote:
> Luke Kenneth Casson Leighton writes:
>
>> i would imagine that inefficient is the _last_ thing on the list of
>> priorities. "technically correctly fulfilling the semantics" i would
>> imagine would be the highest priority.
>>
>> "eff
>> how would you envisage doing client-side SMB named pipes?
>
> By doing the I/O through the wineserver. It has all the necessary
> mechanisms already.
ok - great. whereabouts? which ones? any existing examples? which
existing code in wineserver utilises the existing mechanisms to which
you ref
Luke Kenneth Casson Leighton writes:
> On Wed, Mar 4, 2009 at 2:23 PM, Alexandre Julliard
> wrote:
>> Luke Kenneth Casson Leighton writes:
>>
>>> so - what do people think? would you agree that a user-space pipe
>>> "proxy" is an effective solution?
>>
>> No, you are on the wrong track. That
Luke Kenneth Casson Leighton writes:
> i would imagine that inefficient is the _last_ thing on the list of
> priorities. "technically correctly fulfilling the semantics" i would
> imagine would be the highest priority.
>
> "efficient" and "nice" can always be done later, yes?
No, in many case
On Wed, Mar 4, 2009 at 2:23 PM, Alexandre Julliard wrote:
> Luke Kenneth Casson Leighton writes:
>
>> so - what do people think? would you agree that a user-space pipe
>> "proxy" is an effective solution?
>
> No, you are on the wrong track. That solution is ugly, inefficient, and
i would imagi
On Wed, Mar 4, 2009 at 2:23 PM, Alexandre Julliard wrote:
> Luke Kenneth Casson Leighton writes:
>
>> so - what do people think? would you agree that a user-space pipe
>> "proxy" is an effective solution?
>
> No, you are on the wrong track. That solution is ugly, inefficient, and
> it doesn't he
Luke Kenneth Casson Leighton writes:
> so - what do people think? would you agree that a user-space pipe
> "proxy" is an effective solution?
No, you are on the wrong track. That solution is ugly, inefficient, and
it doesn't help anything since the wineserver constraints that you are
trying to a
the requirements for message-mode named pipes semantics on top of unix
/ wine brings some... interesting limitations on how it can be
implemented, and i believe that i have finally come up with something
that would fit the requirements: the socketpair equivalent of
"double-buffering".
as the imple
15 matches
Mail list logo
