[sldev] How Asset server handles saving of scripts

[John Hurliman]

Donovan Preston wrote:
>
> On Dec 20, 2007, at 1:53 PM, Hamncheese wrote:
>
>> I guess I don't understand "blacklisted at the server" means, unless 
>> you mean that "UpdateScriptTaskInventory" CAPS is turned off on all 
>> sims?
>
> Yep, that's right.
>
>> The code under save if needed does a "get caps from region, if a url 
>> is returned then call uploadAssetViaCaps, if not a valid url call 
>> uploadAssetLegacy" So if CAPS isn't being used until mono is released 
>> why have the check for that CAP in the code for every save?
>
> No reason really, other than we rolled the code out blacklisted and 
> haven't taken the time to QA it and turn it on as a feature separate 
> from mono. If there is sufficient demand it would be easy enough to 
> start a project to turn on the UpdateScriptTaskInventory cap, since 
> the remaining work to be done is QA (currently being done on this 
> feature in the mono branch). But there would have to be a compelling 
> use case.
>
> Donovan

My compelling reason is that the implementation of the Xfer system in 
libsecondlife is the only place in the code that contains swearing and 
desperation in the comments, if all of the uploads were switched to CAPS 
it would make our codebase more family friendly. So there's a "think of 
the children" angle to this discussion. The other reasons include more 
pedantic things like if you start a second upload before the first gets 
a RequestXfer packet back there is no way to discern between the ACKs 
for each upload (the system wasn't designed for parallel uploads at all 
from what I can tell, but it can be done if you are really careful), and 
you have to typecast from a 64-bit integer to a 128-bit UUID (allocating 
a bit of memory) each time a ConfirmXferPacket is received. Speaking of 
which, the two layers of ACKing (PacketAck + ConfirmXferPacket) means it 
uses more bandwidth then a TCP upload would even under perfect network 
conditions. And from an overall protocol design spec it's another 
redundant system to document.

Having said that, there are a lot of other things I'd like to see pushed 
out before retiring the Xfer system. I'm just saying I don't think 
anyone will be sad to see it go.

John