[Opensim-dev] Optimize pushing assets to other grids

[Melanie]

I architected the Robust system and the architectural decision was
to have a different handler for different functionality. The code
duplication is minimal. You merely add another instance of the
stream handler class and ma it to a different url. That is
boilerplate code and duplication is not an issue there. The code
doing the actual work can be shared.

The robust server was not designed to have a "one URL does all"
approach. Please don't break the architecture. All other services
work that way where needed.

Melanie

On 31/03/2014 15:00, Oren Hurvitz wrote:
> As this is an assets-service request, it belongs in the assets-service
> handlers. They already handle many different requests: data, metadata,
> data+metadata, store, update.
> 
> Creating a new handler would be easier for me at this moment, but perhaps
> not best for OpenSim in the longer term. First, because this request is
> related to the other asset requests, it makes sense to handle them
> together. Second, adding a new handler for every new feature isn't good
> because it creates a lot of duplicate code. Third, being able to determine
> a server's capabilities is useful.
> 
> There are many places in the codebase where new features were added using
> copy-paste-and-modify. This makes it harder to add new features, and
> especially hard to refactor major systems because so many places need to be
> changed in parallel. I would like to get away from that.
> 
> Oren
> 
> 
> 
> 
> On Mon, Mar 31, 2014 at 3:51 PM, Melanie-2 [via opensim-dev] <
> ml-node+s2196679n7579101h45 at n2.nabble.com> wrote:
> 
>> Hi Oren,
>>
>> the correct way is to create an additional post handler that is reachable
>> at a different URL, e,g, /AssetQuery/
>>
>> Servers that don't implement it would return 404. Don't try to shoehorn
>> this functionality into the existing post handler.
>>
>> Melanie
>>
>> On 31 Mar 2014, at 13:55, Oren Hurvitz <[hidden email]<http://user/SendEmail.jtp?type=node&node=7579101&i=0>>
>> wrote:
>>
>> I have implemented this method. I found that the Assets Service already
>> had a
>> method to check for assets' existence, so I just had to extend it to check
>> multiple asset ID's at once, and make it available remotely. But now I'm
>> not
>> sure what to do about backwards compatibility.
>>
>> I'm sending the request using POST, because sending a lot of data is
>> better
>> done using POST than GET. But as it turns out, AssetServerPostHandler
>> doesn't handle unknown requests well. First, it assumes that all requests
>> will contain an AssetBase, but this request doesn't. Second, its try/catch
>> clause doesn't catch the exception that is generated, because it's an
>> InvalidOperationException and not an XmlException (which is what's
>> currently
>> caught). The unfortunate result is that the server doesn't send back *any*
>> reply, which means that the caller must wait for the full timeout (100
>> seconds!) before giving up. [BTW, I'm going to investigate this further
>> because it may explain the 100-second timeouts users occasionally
>> experience.]
>>
>> I've already fixed this problem in the current patch (not yet submitted),
>> so
>> that in the future AssetServerPostHandler will return an error code
>> immediately for unknown requests (HTTP 400). But that won't help when
>> connecting to old grids.
>>
>> I see two ways to fix this:
>>
>> 1. Send the request using GET instead of POST. AssetServerGetHandler
>> handles
>> unknown requests a little better than POST: it tries to find the parameter
>> as an Asset ID, but if not found then it just returns HTTP 404
>> immediately.
>>
>> 2. Add a way to query the server for its capabilities, to find out if it
>> supports this request.
>>
>> I prefer approach #2 because it can be used in the future for many other
>> new
>> features. How about adding a method to IGatekeeperService, something like
>> this:
>>
>> Dictionary<string,string> GetServerCapabilities();
>>
>> In this example, the capability will be: "SupportsAssetsExist"="true"
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579100.html
>>
>> Sent from the opensim-dev mailing list archive at Nabble.com.
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email] <http://user/SendEmail.jtp?type=node&node=7579101&i=1>
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email] <http://user/SendEmail.jtp?type=node&node=7579101&i=2>
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>> ------------------------------
>>  If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579101.html
>>  To unsubscribe from Optimize pushing assets to other grids, click here<http://opensim-dev.2196679.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=7579093&code=b3JlbmhAa2l0ZWx5LmNvbXw3NTc5MDkzfDIwMTU3MTI0NTc=>
>> .
>> NAML<http://opensim-dev.2196679.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
> 
> 
> 
> 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev