We have lots of non-core robust services under addon-modules, using the existing core plugin methods. This interface/module is not necessary for any technical reason I can see.
We have addon-module things that are robust services, robust handlers, region modules and any and all of the preceding. All without any extra layers, the mechanism we have already allows out-of-core development and maintenance of such software. There are a few modules in my public addons repo at git://github.com/MelanieT/opensim-modules.git using this mechanism (region modules, but it's the same for ROBUST services and -handlers. Melanie James Hughes wrote: > On 04/25/2011 07:20 AM, Melanie wrote: >> So, if I understand this correctly, it's a unifying framework to >> load http(s) handlers into either a rubust shell or a region server >> without having to make it a full region module? >> >> I believe this is overcomplicating things. If a web service is >> written as a ROBUST handler/service, no shim is needed between >> ROBUST and it. It would only need a shim to load it into a region >> server and that shim could be (and maybe should be) trivially added >> to core. >> >> I see no point in a middleware that abstracts and API by, more or >> less, simply renaming it. >> >> Can you explain what this is meant to facilitate and why new names >> for established APIs are needed? >> >> Melanie >> > > Hi Melanie, > > The intent is to have a generic way to add user developed handlers as > Robust shells to expose internal resources to external applications. For > example, providing a handler that a Web UI could call to create and > manage user accounts. Another case might add a new service that > extends the data. An example that comes to mind is the profile service > that runs in PHP. > > The idea is to provide an easy way to implement those things outside of core > using Robust. But, maybe I'm not seeing the forest for the trees :) > > I will have some time in a couple of days to look at it again. Any > insight to what > I might be overlooking would be welcomed. > > Thanks, > BlueWall > > _______________________________________________ > 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
