The original inventory link handling -- to send the inventory link as well as the original -- was actually very close. The only problem with it was that it sent the link and then the original, so that when the viewer received the link, it reported a lot of broken links and other problems in the viewer log. These were not seen at the user level, but while attempting to fix some of the other problems (now fixed elsewhere), of course the link-related errors stood out as a problem. However, with those other problems fixed, and broken links still showing, I reexamined the original implementation, along with the viewer code.
The viewer code shows a complete lack of resolving (forward) links once the inventory completes. It does not reexamine broken links after receiving new inventory folder contents. However, it does have some pretty good flexibility in receiving inventory items. Results of my viewer observations:
When requesting the contents of a folder, the server is allowed to respond with something in a different folder, mixed with the requested one. (i.e. items with different parent IDs)
The server is allowed to send the same item (or folder) more than once. Receipt of an item a second time merely replaces the one it already had.
When receiving an item that does not live in the current (requested) folder, if the parent ID is unknown, the viewer will create a dummy stub node for that folder.
Points 1 means that it is safe to send the duplicate items with the links to them, as long as the correct (different) parent ID is specified with the original. And if that parent is not yet known, point 3 means that will still be allowed, at least until inventory is fully loaded. Point 2 means that when the server gets to the original, it's perfectly fine to send it again, or as many times for as many copies of links are in the inventory.
This PR reverts the original change that I made to remove the duplicates. The only problem with the original code is that the original must be sent before the link, so the second commit in this PR makes that tweak.
When combined with the other fixes, the viewer logs are much much cleaner, and the user-level functionality seems much more reliable. (This should mean that we've fixed the problems Astoria and others were having.)
The original inventory link handling -- to send the inventory link as well as the original -- was actually very close. The only problem with it was that it sent the link and then the original, so that when the viewer received the link, it reported a lot of broken links and other problems in the viewer log. These were not seen at the user level, but while attempting to fix some of the other problems (now fixed elsewhere), of course the link-related errors stood out as a problem. However, with those other problems fixed, and broken links still showing, I reexamined the original implementation, along with the viewer code.
The viewer code shows a complete lack of resolving (forward) links once the inventory completes. It does not reexamine broken links after receiving new inventory folder contents. However, it does have some pretty good flexibility in receiving inventory items. Results of my viewer observations:
Points 1 means that it is safe to send the duplicate items with the links to them, as long as the correct (different) parent ID is specified with the original. And if that parent is not yet known, point 3 means that will still be allowed, at least until inventory is fully loaded. Point 2 means that when the server gets to the original, it's perfectly fine to send it again, or as many times for as many copies of links are in the inventory.
This PR reverts the original change that I made to remove the duplicates. The only problem with the original code is that the original must be sent before the link, so the second commit in this PR makes that tweak.
When combined with the other fixes, the viewer logs are much much cleaner, and the user-level functionality seems much more reliable. (This should mean that we've fixed the problems Astoria and others were having.)