WHAT

 Big redesign and rename of the main internal curl handle 'struct UrlData'.

WHY

 The 'UrlData' struct has been left to grow wild and uncontrolled, when we
 discuss adding new functions to the libcurl API, we've experienced that we
 don't have enough "control" over the struct fields.

 There's this huge struct with lots of mixed fields, many of them are set
 with *_setopt() calls, some are modified along the way, some are used just
 for library-wide state data.

 To say the least, it started to get confusing and mistakes were easly made
 in regard to which fields that needed to be free()ed after user and so on.

 The recent initiative to add a '*_duphandle()' function also called for some
 drastic action so that we won't introduce a lot of problems with such a new
 function.

 Hopefully, we get clearer definitions for each kind of data and it makes it
 easier to understand more parts of the libcurl source code.

NOW

 The new main curl handle struct is named 'SessionHandle'. It holds all data
 connected to a "session" (that is the entire life-time between an *_init()
 call and the *_cleanup() call).

 The SessionHandle itself is divided into several sections, each represented
 by its own sub-struct (the actual names of them are not so important):

  USER DEFINED
    This struct contains all user-defined data, as setup with *_setopt().
    They should never be modified in this struct, but the plain input values
    should be stored. Examples: 'follow locations' and 'use FTP PORT command'.

  CHANGED
    Data that is used from the user defined area, but that might need to get
    modified. They're copied into the 'changed' are and are used in there.
    Examples: URL (as that is modified when following a Location: and more)
    and proxy (which can be copied from environment variables etc)

  COOKIES
    Because they have a slightly separate engine and live their own lifes.

  PROGRESS
    Data used for the progress data display, speed limit checker and some of
    the informational data you can get afterwards that the progress meter
    code has calculated.

  STATE
    Internal state information. Buffers and general library-wide data we want
    to pass around and keep.

  INFO
    Purely informational data, stored to be able to get retrieved later with
    the *_getinfo() call.

FILE NAME

 Yes, all these structs are defined in the same file and I kept the name
 lib/urldata.h to minimize the inpact on makefiles etc.

BUGS

 I'm not 100% sure of all where all the struct fields have been stashed right
 now, but I expect them to settle soon. It shouldn't be anything any
 "outsider" is gonna notice.

 I intend to release another 7.9 pre-release ASAP so that there's a good
 tarball to test and base future patches on. I've already committed the
 changes to CVS (and I did tag them before I did that, so there's a way back
 in case everything hits the fan!)

Questions? :-)

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/