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+s2196679n7579101...@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>
>
--
Oren Hurvitz
VP R&D
Kitely Ltd.
Email: or...@kitely.com <i...@kitely.com>
--
View this message in context:
http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579102.html
Sent from the opensim-dev mailing list archive at Nabble.com.
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
