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.
Note: Large groups still don't load?!
SimConsole cap is needed for Sim Console, won't work without it, keeping it in!
..But it should work with the new ASync one? Maybe needs tweaks, first?
Also switches opening IMs to the gCacheName->getFullName(id, name) system mentioned earlier, my connection has improved!
And makes the Avatar Picker show display names! Yay! (Rearranged the includes there, alphabetical~)
Also fallback to gCacheName->getFullName(id, name) if getting name fails in the new system.. hopefully this will combat occasional big failures.. but it may not work anyway.. maybe my connection is just awful again
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!
The AIBufferedCurlEasyRequestEvents are not triggered unless
the derived class return true for needsHeaders().
That means, every class that implements received_HTTP_header(),
received_header() or completed_headers(), or implement
the virtual function completedHeaders(), or use the protected
member mReceivedHeaders directly.
This commits adds missing needsHeaders() for LLAvatarNameCache
(thanks Siana) and XMLRPCResponder. The former now uses
mReceivedHeaders directly instead of making a copy.
* Moved Responder stuff to LLHTTPClient.
* Renamed LLHTTPClient::Responder to LLHTTPClient::ResponderWithResult.
* Deleted LLHTTPClientAdapter and LLHTTPClientInterface.
* Renamed AICurlInterface::TransferInfo to AITransferInfo and moved it
to llhttpclient.h
* Removed 'CURLcode code' argument from completed_headers.
* Removed LLCurlRequest and replaced it's last usage with LLHTTPClient API calls.
* Deleted dead code.
* Renamed all the get4/post4/put4/getByteRange4 etc, back to their
original name without the '4'.
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").
Introduces AIHTTPTimeoutPolicy objects which do not just
specify a single "timeout" in seconds, but a plethora of
timings related to the life cycle of the average HTTP
transaction.
This knowledge is that moved to the Responder being
used instead of floating constants hardcoded in the
callers of http requests. This assumes that the same
timeout policy is wanted for each transaction that
uses the same Responder, which can be enforced is needed.
I added a AIHTTPTimeoutPolicy for EVERY responder,
only to make it easier later to tune timeout values
and/or to get feedback about which responder runs
into HTTP errors in debug output (especially time outs),
so that they can be tuned later. If we already understood
exactly what we were doing then most responders could
have been left alone and just return the default timeout
policy: by far most timeout policies are just a copy
of the default policy, currently.
This commit is not finished... It's a work in progress
(viewer runs fine with it though).
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.
Excluded llareslistener, as that appears to only be present for unit-testing
Excluded new SSL methods because, well, they don't work right reliably in v2 for me
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.
