Sorry for venting, Dan!

Dan Fandrich wrote:
> I'm not the gatekeeper here, but my feeling was that there must be a better
> way. But code speaks louder than words!

I agree - my original patch was a bit of a hack. But there's no easy,
clean solution here. The clean solutions aren't easy and vice versa.

> We appreciate the time you're spending on trying to get this going, but
> right now you're the only one who's in a position to test these changes.
> Those of us here in the peanut gallery don't have enough data yet to make
> an intelligent observation on the best way forward. Producing a patch that
> works for you is the best way for everyone to review the proposed change.

> You're certainly free to get this going for yourself whichever way is
> most simple, but if that way impedes the long-term maintainability of the
> curl sources then it's not necessarily the best approach to apply to
> the official curl source tree. Since in this case it looks like curl has
> to go through gyrations (one way or another) to work around a broken
> third-party library, and there are very few users it affects, it may be
> best to wait and fix that library instead.

That's fine. Again, I'm more than happy to do the coding/testing to get
this patched, but with the caveat that I just don't have a lot more time
to spend on this. So if you'd like me to patch this I'd like to get it
ironed it out soon.

As you know, I supplied a patch for this already, but it's ugly/hacky.
I do agree that Yang's approach would be cleaner, but as I already
pointed out it won't compile due to another include in the MIT code.

So seems to me there's really only a few remaining possibilities then:

1) as you suggested earlier, refactor the curl code a bit to move most
of the GSS/MIT-specific code from urldata.h and isolate it in krb5.c.
Then it'd probably be OK for that code to be more tied to MIT.

2) change the names of most of the preprocessing directives in
config-win32.h so that they no longer conflict with MIT (e.g.,
HAVE_STRDUP -> CURL_HAVE_STRDUP)

3) have a pow-wow with one of the MIT Kerberos devs and hash this out
with them.

I'm not really familiar enough with the curl code to choose a course on
this myself, though. (As you mentioned, long-term maintainability is at
stake here.) Perhaps you and Yang can reach a consensus on how you want
to do this, and then I can submit you guys another patch?

DR
Received on 2008-05-23