<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
After more poking at the viewer, here's what I found. <br>
<br>
FetchInventoryDescendents seems to be working consistently over CAPs,
in fact better than over UDP. When the agent logs in, the client always
invokes that CAP, unlike the message over UDP which only seems to come
after a clear cache. That first FetchInventoryDescendents request is
for getting the 1st-level items just below the Root folder. Whenever
you unfold folders, this CAP is invoked too, and that happens all the
time. In other words, the inventory skeleton is passed in a lazy mode
to the client, and directly from wherever this Capability is being
served. Why is this commented in the code? <br>
<br>
Observation #1: we could make the provider of this CAP be the inventory
service, instead of the region. That way, the user can *browse* the
contents of her inventory *safely everywhere* -- even if the region
where she is doesn't have her inventory.<br>
<br>
Unfortunately, the goodies sort of stop here. I tried coercing the
viewer to use FetchInventory, CreateInventoryItem,
CreateInventoryFolder, and other inventory manipulation operations,
over CAPs, but the viewer doesn't seem to want to do that. The only
ones that are over CAPs are the ones we already have related to
notecards and scripts. Those can also be split eventually, some of them
should go to the inv server directly, namely: NewFileAgentInventory,
UpdateNotecardAgentInventory, UpdateScriptAgentInventory. There's
really no need to let the regions serve these.<br>
<br>
However, even though inventory access doesn't seem to be entirely over
CAPs, not all is lost. What this means is that we can stop regions (the
untrusted ones, at least) from getting the user's inventory in its
entirety while the user still *sees* it. The next problem is *access*.
That is, I can see I have a shape in there, but as soon as I try to
wear it, that fails, because the region where I am doesn't known
anything about it (it doesn't have the assetID, because it doesn't have
the inventory). <br>
<br>
We have three options here.<br>
<br>
(1) We have the region fetch that inventory item from the user's
inventory, and then send it to the viewer; so the region gets a copy of
the item.<br>
(2) We have the region serve merely as front-end of the request,
passing it to the user's inventory server or home region, and have them
send the actual item to the viewer. (my favorite; in this case,
Identity and Authentication would be established by the viewer's
EndPoint, again)<br>
(3) We simply don't serve the item.<br>
<br>
In any case, the great thing here is that the region doesn't have the
complete listing of the users' inventory items, but the viewer does.
That is, we avoid that dreadful "Loading...". The region may get
requests for fetching items, and those IDs come from the client. So
when the inv server gets a request to fetch an item, we know that with
all likelihood this request came from the legitimate viewer; the odds
of the region guessing a valid itemID are pretty low.<br>
<br>
---<br>
<br>
I can already hear Melanie saying that any of this is going to break 57
things related to attachments and scripting :-) That's ok. I'm talking
about crossing boundaries of trust for now, so Hypergrid, OSGrid and
others like that. And there's ways of not breaking attachments and
scripts across region boundaries.<br>
<br>
My main objective is to defeat what I've put DNCH doing at the moment
-- wiping out people's inventories. <br>
<br>
Melanie wrote:
<blockquote cite="mid:49A70539.2000601@t-data.com" type="cite">
<pre wrap="">That is what was said. Linden reverted the inventory protocol to UDP
on their servers because of an issue in the viewer that was so
fundamental that it was decided to not be worth fixing.
Whether this is true, I don't know. but it was said.
Melanie
Diva Canto wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Melanie wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Linden turned it off because it's broken in the client. So, we can
try to use it but will hit the same wall, since the client was never
fixed.
</pre>
</blockquote>
<pre wrap="">Melanie: are you 100% sure about this? This, of course, is critical. The
whole point of my thinking was to access inventory over the consistent
model of CAPs; if that's not working, then everything else is minor.
_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>