Conflicts:
indra/newview/llfloateravatarpicker.cpp - Includes to v-d style, since plain alphabetical just won't cut it. Shyotl's changes for name system, here.
indra/newview/llpanelgroupinvite.cpp - Shyotl's changes for name system, here.
Also corrected new README to have less typos and be slightly more accurate.
Better viewed without space changes
Pretty much add support for sending LLAvatarName and std::string to become a name via the system...
Also a bit of a revert for llcallingcard.cpp in this regard, just allow it to use a callback along with the new support,
but still handle the actual name switching in LLAvatarNameCache.
Fixes a problem I was having with "[NAME] is Online" notifications appearing early on, only.
Only does that, dun believe me? Take a look, oh... it also corrects improper interpretations of the PhoenixNameSystem value: 1 is both, 2 is displays, 0 and anything else is Legacy.
Also replaces a bit of the display name support code with new system... by definition this shouldn't change the log file, only the title of the session..
because of my bad connection during week days, I can not confirm this working 100%,
but if it does end up changing the logs under certain unseen conditions, replace the new name check with gCacheName->getFullName(id, name) but this reallllly shouldn't happen!
This fixes the problem that existed with received headers:
The server sends some headers ("set-cookie") more than once
in the same reply, which cannot be stored in std::map.
The old code just ignored the additional cookies, while
curlthreading3 (since the introduction of AIHTTPHeaders)
caused an assertion.
AIHTTPReceivedHeaders is written around a std::multimap
and allows to retrieve multiple headers with the same key.
Also, it is case insensitive so that if a server sends
"Content-Type" it will still find it (the viewer looks for
"content-type").
This creates a separate events interface structure
for CurlResponderBuffer (AICurlResponderBufferEvents)
for dealing with received HTTP headers.
The headers are passed to the Responder, but only
if the class derived from Responder implements
completedHeaders (otherwise it makes little sense
to even decode the headers).
Basically this is a reimplementation of the functionality
of the old LLHTTPClientURLAdaptor class.
That's quite a piece of work. I have NO idea how Jess can downplay the
effort that went into this.
And it's still not complete, local chat is not affected, perhaps group
chat too.
