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] < > [email protected]> 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 > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
