On Thu, 3 Jan 2013, Yang Tse wrote:

> 1) We are able to guarantee to a higher degree that the headers being
> included are actually libcurl ones.

I'm not a fan of fixing *potential* problems. We've managed fine for 14 years
with this naming, I don't see anything new on the horizon that suddenly made
the system break that needed this massive change.

> 2) Specifically, renaming setup.h and setup_once.h to curl_setup.h and
> curl_setup_once.h was needed to break bidirectional interdependency on
> c-ares files when building with c-ares in-tree. This change alone modified
> same big number of files.

Building c-ares in-tree is an ancient tradition that we should NOT preserve at
the expense of anything in the curl project. Not even I build c-ares in-tree
anymore and we shouldn't encourage anyone in doing so either. I would much
prefer we just proclaimed it not supported anymore and have a nicer build
environment for curl.

> 3) Points above are in preparation of at-some-future point splitting
> of curl_setup_once.h into two headers, one that is required to be
> included in libcurl's sources before other libcurl headers and another
> one that has to be included nearly last although not for the same
> reasons an curl_memdebug.h

The splitting of a single header or two surely can't motivate the renaming of
190 *other* files?

> 4) When human reading libcurl's code it is much easier to know if a
> header is a libcurl header or not.

Sure, I'll give you that. But on the other hand, you've now alienated all of
us old-timers from our own code base. What we formerly knew so intimately is
now gone. I find this to be a *really* hard blow against my productivity. I
know (and use) a large amount of header names and off the top of my head and I
use them frequently.

> 5) Script testing of conditions relative to positioning or presence of
> libcurl's headers in source files will become less error prone.

I disagree. That script test only needs a single or two files, and we already
had several files named curl_* to use for that.

> 6) When referencing the name of a libcurl header file either on the
> mailing list or wherever it becomes obvious that it is a libcurl one.

True, but that's making up a solution to a problem we never had...

> 2) When debugging libcurl or apps that use it with debuggers that are
> capable of showing the name of the source file it is much easier to know if
> one is stepping in libcurl's code or elsewhere.

Yes sure, but that hasn't ever been a problem either and you've instead
introduced problems that the file names have turned very long and instead make
outputs wrap and be harder to read.

For me, that's about the same reason I try to use short function names. I want
short(ish) file names as well to reduce the amount of info my brain needs to
absorb.

> 3) On core dumps, and fatal happenings which trace the source file
> name of where the problem has been triggered, it becomes much easier
> for not expert souls to figure out if it is a libcurl problem or not.

I would be surprised if this will help anyone. If you're clever enough to read
a back trace of a core dump to get info from it, I'm sure you can figure out
which library the functions belong to.

> 4) Also makes naming of *.c files equal to respective *.h one.

Right, but I am against both renames so that's not a benefit.

Further downsides with the renames:

* Patches for older curl versions now suddenly don't apply anymore and will
   give us (and others) much more work to apply. This will not only affect a
   couple of patches that I have pending in the mailing list but also in the
   bug tracker. There's also about a bazillion distros out there with distro
   specific patches that suddenly get version-specific file name changes
   (where the patches could otherwise apply to multiple versions).

* History tracking/git log is much harder and annoying with file renames. So
   while it can be handled, things like the github's history breaks and
   bisecting things will require more work.

Sorry, but my vote goes to reverting the renaming of the headers and the
source files.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html