Then the solution is to generalize the code, not to overburden it. If handling different URI forces dupe code then there was a very bad decision made very long ago.
I bet it is threaded crap. On Mon, Mar 31, 2014 at 9:00 AM, Oren Hurvitz <or...@kitely.com> 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] <[hidden > email] <http://user/SendEmail.jtp?type=node&node=7579102&i=0>> 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. >> 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: [hidden > email]<http://user/SendEmail.jtp?type=node&node=7579102&i=1>[hidden > email] <http://user/SendEmail.jtp?type=node&node=7579102&i=2> > > ------------------------------ > View this message in context: Re: Optimize pushing assets to other > grids<http://opensim-dev.2196679.n2.nabble.com/Optimize-pushing-assets-to-other-grids-tp7579093p7579102.html> > Sent from the opensim-dev mailing list > archive<http://opensim-dev.2196679.n2.nabble.com/>at Nabble.com. > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev > -- No essence. No permanence. No perfection. Only action.
_______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
