[RFC] named pipe message-mode design

Luke Kenneth Casson Leighton lkcl at lkcl.net
Wed Mar 4 15:00:56 CST 2009


On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard <julliard at winehq.org> wrote:
> Luke Kenneth Casson Leighton <lkcl at lkcl.net> 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 cases efficiency needs to be taken into account in the
> design phase. You can't just add it later.

 sure you can.  by redesigning.

 and because the functionality is encapsulated, fulfilling the
requirements behind a well-documented immutable API, other teams can
move forward (even if they're complaining about speed) opening up
entirely new areas of functionality and opportunities for Wine,
bringing in more interested developers, one of whom _might_ be skilled
enough and interested enough to go "that design - it's crap!  i can do
better!" and thus you get a better, more efficient and much more
acceptable ...

_incremental_ improvement.

 so by shutting the door on an idea because it's "inefficient" and
"not nice" you risk losing my input, and an opportunity to get the
ball rolling.

 i'm not interested at this stage in making a "nice or efficient"
design, i'm interested in getting a "technically correct" design - and
a reliable, working implementation.

l.



More information about the wine-devel mailing list