Re: [Gnu-arch-users] Nit

[Tom Lord]

    > From: Joshua Haberman <address@hidden>

    > On Sun, 2003-10-19 at 13:00, Tom Lord wrote:
    > > But look, ultimately it's a cost/value trade-off.   You think the cost
    > > is low enough?  You do it.   Go ahead -- do a good job of transforming
    > > libarch to be binding friendly.    Probably only take a week or
    > > two....

    > I was under the impression that you were fundamentally opposed to seeing
    > libarch wrappers.  If it's just a question of who will do the work, then
    > we have no argument.

Not fundamentally, no.   It is a cost/value trade-off.

Here's the thing:  to do it well, you need to address those issues
we've discussed (especially error propogation).

Ideally, such changes are "correctness preserving" -- you send me a
patch, I review it, it's obvious that it doesn't break anything --
we're all happy.

In reality, there's just a huge number of nebbishy little details to
get right here and the nature of these changes is that they risk being
quite destablizing.   Walters' work on the test suite is a big help
here and one way to make such changes easier to accept is to
interleave them with new tests for the corresponding commands.

Another thing is "what new conventions are involved?"  If you were to
propose changes that would make maintaining libarch for the purposes
of tla distinctly harder, then I'm not too fond of that.

Finally, I think it's a _little_ silly to make libarch binding-safe
just for the sake of accomplishing that abstract goal.  I'd much
rather see a process like:

        1) prototype a higher-level application using the fork/exec
           approach.   Demonstrate with this app that the libarch 
           changes would be a win.

        2) Start on the libarch changes.

I don't think that the constraint of sticking to fork/exec for (1) is
a serious bottleneck to demonstrating a high-level app.

On the other hand, it surely does appear to be the case that, unlike
releasing a decent CLI, if you release a library that a lot of today's
free software participants then "know what to do".  So, the
requirement of (1) first is not a firm requirement -- just a
suggestion.

-t