[RFC] named pipe message-mode design

[Ben Klein]

2009/3/5 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:
> On Thu, Mar 5, 2009 at 3:06 AM, Ben Klein <shacklein at gmail.com> wrote:
>> 2009/3/5 Luke Kenneth Casson Leighton <lkcl at lkcl.net>:
>>> 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.
>>
>> So you're saying that your original design is wasted effort?
>
>  no, i'm saying that it opens up the doors to the next level for wine
> - networked msrpc interoperability.

But if you already admit that your original design needs a complete
redesign, what makes you think Wine should even consider your first
design?

>>  If it CAN
>> be redesigned to be efficient, nice, sensible and correct, it's worth
>> doing that from the start, especially in a big project such as Wine.
>
>  yes it would be nice, wouldn't it.
>
>  however, if there's a nicer design that would involve _more_ effort
> on my part rather than less, then offers of money should accompany the
> requests to implement the better design, to compensate me for the
> additional time spent.

You seem to be confusing "opensource developed by volunteers" with
"commercial project developed by employees".

You mention "incremental improvements" several times, but there have
already been objections to your design *from the project leader*. This
means that if you do go through with an implementation based on this
design, you will be wasting your time and effort, as it will never be
accepted upstream.

> if however the nicer design turns out to involve _less_ effort on my
> part, i'm very very happy.

More effort is required in researching and developing the design
(because you already have a rejected design). But if the "nicer"
design is done well, it will be _less_ effort to implement, and a lot
less effort for other people to interpret and maintain should they
need to. This is not *your* project; it's opensource, and AJ has
strict rules on quality of code that anyone contributing patches has
to deal with.

I'm not trying to discourage you from presenting and/or implementing a
good design, just trying to address some misconceptions you seem to
have about the Wine project and software development in general.