2009/3/5 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Thu, Mar 5, 2009 at 3:06 AM, Ben Klein shacklein@gmail.com wrote:
2009/3/5 Luke Kenneth Casson Leighton lkcl@lkcl.net:
On Wed, Mar 4, 2009 at 6:10 PM, Alexandre Julliard julliard@winehq.org wrote:
Luke Kenneth Casson Leighton lkcl@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.