Reducing the plugin mechanisms

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Reducing the plugin mechanisms

Diva Canto
We had this conversation today in the IRC about the several plugin
mechanisms currently being used by assorted parts of OpenSim. A couple
of years ago, we made a big push towards the [new] Region Modules
mechanism, and that placed about 95% of simulator plugins in that
bandwagon. However, a couple of them are still using their own raw
"pluginning," and that makes them hard to (1) explain and (2) distribute
as 3rd party packages. They were left behind.

One of them is Physics, the other is the client implementations. I would
like to propose that we move these last 2 renegades to the Region Module
plugin mechanism, so to reduce entropy and to make them easier to
package. From our conversation, moving the Physics plugins to region
modules is peaceful. I haven't looked at the client dll yet, but I've
been told that people experimenting with other client protocols are
using region modules anyway.

This affects the MOSES group developing the PhysX plugin, but it should
be straightforward to adjust and it has advantages. Once we move the
existing physics plugins to this new mechanism, you should be able to do
exactly the same to yours -- the changes aren't that big, and it doesn't
affect the Physics interface at all; it's just the way of connecting the
physics implementation to the interface. Plus it will make it somewhat
easier for you to make your physics plugin available for external
testers at intermediate (early) times, if you want.

Any objections?

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reducing the plugin mechanisms

Dahlia Trimble
I like this idea. I have done some physics via the region module interface and had pretty good luck. I've also done client protocol implementations in region modules and I can say that the available interfaces are incomplete for the purposes of the entire LL protocol suite. I use EventManager for tracking scene changes and this seems to work ok for the most part but I don't believe events exist for all events a normal viewer would care about. There is also the issue of managing presences, teleports and region border crossings. I've done some workarounds here but it's not pretty. I suspect a lot of changes to related framework code would need to be done to be successful. I'm also not sure if EventManager events are as efficient and CPU friendly as the direct calls which go thru IClientAPI but I can't say I've seen anything to suggest (yet) that this could be a problem. There are also some efficiency hacks in llClientView and related code (lazy packet initialization for one) which might not easily translate to a region module.

Regardless, it sounds like a good experiment to try :)

On Sun, Aug 16, 2015 at 6:44 PM, Diva Canto <[hidden email]> wrote:
We had this conversation today in the IRC about the several plugin mechanisms currently being used by assorted parts of OpenSim. A couple of years ago, we made a big push towards the [new] Region Modules mechanism, and that placed about 95% of simulator plugins in that bandwagon. However, a couple of them are still using their own raw "pluginning," and that makes them hard to (1) explain and (2) distribute as 3rd party packages. They were left behind.

One of them is Physics, the other is the client implementations. I would like to propose that we move these last 2 renegades to the Region Module plugin mechanism, so to reduce entropy and to make them easier to package. From our conversation, moving the Physics plugins to region modules is peaceful. I haven't looked at the client dll yet, but I've been told that people experimenting with other client protocols are using region modules anyway.

This affects the MOSES group developing the PhysX plugin, but it should be straightforward to adjust and it has advantages. Once we move the existing physics plugins to this new mechanism, you should be able to do exactly the same to yours -- the changes aren't that big, and it doesn't affect the Physics interface at all; it's just the way of connecting the physics implementation to the interface. Plus it will make it somewhat easier for you to make your physics plugin available for external testers at intermediate (early) times, if you want.

Any objections?

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reducing the plugin mechanisms

Diva Canto
I'm not suggesting getting rid of IClientAPI...
I mean I *wish* we would get rid of it, but that's not what I'm proposing here. I'm just proposing replacing the ad-hoc reflective instantiation of IClientNetworkServer that ClientStackManager is currently doing with a more in-style Region Module.

On 8/16/2015 6:55 PM, Dahlia Trimble wrote:
I like this idea. I have done some physics via the region module interface and had pretty good luck. I've also done client protocol implementations in region modules and I can say that the available interfaces are incomplete for the purposes of the entire LL protocol suite. I use EventManager for tracking scene changes and this seems to work ok for the most part but I don't believe events exist for all events a normal viewer would care about. There is also the issue of managing presences, teleports and region border crossings. I've done some workarounds here but it's not pretty. I suspect a lot of changes to related framework code would need to be done to be successful. I'm also not sure if EventManager events are as efficient and CPU friendly as the direct calls which go thru IClientAPI but I can't say I've seen anything to suggest (yet) that this could be a problem. There are also some efficiency hacks in llClientView and related code (lazy packet initialization for one) which might not easily translate to a region module.

Regardless, it sounds like a good experiment to try :)

On Sun, Aug 16, 2015 at 6:44 PM, Diva Canto <[hidden email]> wrote:
We had this conversation today in the IRC about the several plugin mechanisms currently being used by assorted parts of OpenSim. A couple of years ago, we made a big push towards the [new] Region Modules mechanism, and that placed about 95% of simulator plugins in that bandwagon. However, a couple of them are still using their own raw "pluginning," and that makes them hard to (1) explain and (2) distribute as 3rd party packages. They were left behind.

One of them is Physics, the other is the client implementations. I would like to propose that we move these last 2 renegades to the Region Module plugin mechanism, so to reduce entropy and to make them easier to package. From our conversation, moving the Physics plugins to region modules is peaceful. I haven't looked at the client dll yet, but I've been told that people experimenting with other client protocols are using region modules anyway.

This affects the MOSES group developing the PhysX plugin, but it should be straightforward to adjust and it has advantages. Once we move the existing physics plugins to this new mechanism, you should be able to do exactly the same to yours -- the changes aren't that big, and it doesn't affect the Physics interface at all; it's just the way of connecting the physics implementation to the interface. Plus it will make it somewhat easier for you to make your physics plugin available for external testers at intermediate (early) times, if you want.

Any objections?

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reducing the plugin mechanisms

Dahlia Trimble
Awww you had me excited for a moment there....

Regardless, it would be helpful to be able to create presences via region modules and have them be full-fledged presences from the perspective of grid services. This is currently a big stumbling block for implementing client protocols in region modules. There are also LL client dependencies which also make it difficult, or even impossible to create a fully capable grid managed presence in another IClientAPI implementation beside llClientView, so something eventually needs to happen here if anyone wants to get really serious about OpenSimulator supporting other protocol implementations besides the LL protocols. Without such, web-based and other clients are doomed to be second class citizens unless they use a proxy which translates to LL protocols.

On Sun, Aug 16, 2015 at 8:43 PM, Diva Canto <[hidden email]> wrote:
I'm not suggesting getting rid of IClientAPI...
I mean I *wish* we would get rid of it, but that's not what I'm proposing here. I'm just proposing replacing the ad-hoc reflective instantiation of IClientNetworkServer that ClientStackManager is currently doing with a more in-style Region Module.


On 8/16/2015 6:55 PM, Dahlia Trimble wrote:
I like this idea. I have done some physics via the region module interface and had pretty good luck. I've also done client protocol implementations in region modules and I can say that the available interfaces are incomplete for the purposes of the entire LL protocol suite. I use EventManager for tracking scene changes and this seems to work ok for the most part but I don't believe events exist for all events a normal viewer would care about. There is also the issue of managing presences, teleports and region border crossings. I've done some workarounds here but it's not pretty. I suspect a lot of changes to related framework code would need to be done to be successful. I'm also not sure if EventManager events are as efficient and CPU friendly as the direct calls which go thru IClientAPI but I can't say I've seen anything to suggest (yet) that this could be a problem. There are also some efficiency hacks in llClientView and related code (lazy packet initialization for one) which might not easily translate to a region module.

Regardless, it sounds like a good experiment to try :)

On Sun, Aug 16, 2015 at 6:44 PM, Diva Canto <[hidden email]> wrote:
We had this conversation today in the IRC about the several plugin mechanisms currently being used by assorted parts of OpenSim. A couple of years ago, we made a big push towards the [new] Region Modules mechanism, and that placed about 95% of simulator plugins in that bandwagon. However, a couple of them are still using their own raw "pluginning," and that makes them hard to (1) explain and (2) distribute as 3rd party packages. They were left behind.

One of them is Physics, the other is the client implementations. I would like to propose that we move these last 2 renegades to the Region Module plugin mechanism, so to reduce entropy and to make them easier to package. From our conversation, moving the Physics plugins to region modules is peaceful. I haven't looked at the client dll yet, but I've been told that people experimenting with other client protocols are using region modules anyway.

This affects the MOSES group developing the PhysX plugin, but it should be straightforward to adjust and it has advantages. Once we move the existing physics plugins to this new mechanism, you should be able to do exactly the same to yours -- the changes aren't that big, and it doesn't affect the Physics interface at all; it's just the way of connecting the physics implementation to the interface. Plus it will make it somewhat easier for you to make your physics plugin available for external testers at intermediate (early) times, if you want.

Any objections?

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reducing the plugin mechanisms

Diva Canto
Yes, that dragon needs to be slayed. See note #1 on my "Future of OpenSimulator" message. It would be nice to actually see the concrete struggles of those other clients, though.

On 8/16/2015 9:14 PM, Dahlia Trimble wrote:
Awww you had me excited for a moment there....

Regardless, it would be helpful to be able to create presences via region modules and have them be full-fledged presences from the perspective of grid services. This is currently a big stumbling block for implementing client protocols in region modules. There are also LL client dependencies which also make it difficult, or even impossible to create a fully capable grid managed presence in another IClientAPI implementation beside llClientView, so something eventually needs to happen here if anyone wants to get really serious about OpenSimulator supporting other protocol implementations besides the LL protocols. Without such, web-based and other clients are doomed to be second class citizens unless they use a proxy which translates to LL protocols.

On Sun, Aug 16, 2015 at 8:43 PM, Diva Canto <[hidden email]> wrote:
I'm not suggesting getting rid of IClientAPI...
I mean I *wish* we would get rid of it, but that's not what I'm proposing here. I'm just proposing replacing the ad-hoc reflective instantiation of IClientNetworkServer that ClientStackManager is currently doing with a more in-style Region Module.


On 8/16/2015 6:55 PM, Dahlia Trimble wrote:
I like this idea. I have done some physics via the region module interface and had pretty good luck. I've also done client protocol implementations in region modules and I can say that the available interfaces are incomplete for the purposes of the entire LL protocol suite. I use EventManager for tracking scene changes and this seems to work ok for the most part but I don't believe events exist for all events a normal viewer would care about. There is also the issue of managing presences, teleports and region border crossings. I've done some workarounds here but it's not pretty. I suspect a lot of changes to related framework code would need to be done to be successful. I'm also not sure if EventManager events are as efficient and CPU friendly as the direct calls which go thru IClientAPI but I can't say I've seen anything to suggest (yet) that this could be a problem. There are also some efficiency hacks in llClientView and related code (lazy packet initialization for one) which might not easily translate to a region module.

Regardless, it sounds like a good experiment to try :)

On Sun, Aug 16, 2015 at 6:44 PM, Diva Canto <[hidden email]> wrote:
We had this conversation today in the IRC about the several plugin mechanisms currently being used by assorted parts of OpenSim. A couple of years ago, we made a big push towards the [new] Region Modules mechanism, and that placed about 95% of simulator plugins in that bandwagon. However, a couple of them are still using their own raw "pluginning," and that makes them hard to (1) explain and (2) distribute as 3rd party packages. They were left behind.

One of them is Physics, the other is the client implementations. I would like to propose that we move these last 2 renegades to the Region Module plugin mechanism, so to reduce entropy and to make them easier to package. From our conversation, moving the Physics plugins to region modules is peaceful. I haven't looked at the client dll yet, but I've been told that people experimenting with other client protocols are using region modules anyway.

This affects the MOSES group developing the PhysX plugin, but it should be straightforward to adjust and it has advantages. Once we move the existing physics plugins to this new mechanism, you should be able to do exactly the same to yours -- the changes aren't that big, and it doesn't affect the Physics interface at all; it's just the way of connecting the physics implementation to the interface. Plus it will make it somewhat easier for you to make your physics plugin available for external testers at intermediate (early) times, if you want.

Any objections?

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev




_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reducing the plugin mechanisms

Dahlia Trimble
If you mean how hooks have been added for supporting out-of-core modules, sure I agree.  I've added several hooks and events myself and I'll likely add more. Usually when I do I add in-code documentation (which should work with automatic documentation programs like doxygen) so others can take advantage of them and to reduce the probability that they are deleted or unnecessarily modified by other contributors.

Another reason I like the idea of using Region Modules for clients is IClientAPI methods are designed around the messages the LL client uses. I'm only aware of 2 (marginally) successful non-LL network-based IClientAPI implementations in the past; one I wrote for use with a Unity3D based viewer I was working on several years ago, and one that used a "Bubble" grid concept that was implemented in IdealistViewer. These experiences have contributed much to my general distaste of IClientAPI. Region modules and EventManager are more stable (in the sense that the interfaces change less) and seem much more generic than the very specialized IClientAPI and hence more suitable for non-LL clients.

On Sun, Aug 16, 2015 at 9:22 PM, Diva Canto <[hidden email]> wrote:
Yes, that dragon needs to be slayed. See note #1 on my "Future of OpenSimulator" message. It would be nice to actually see the concrete struggles of those other clients, though.

On 8/16/2015 9:14 PM, Dahlia Trimble wrote:
Awww you had me excited for a moment there....

Regardless, it would be helpful to be able to create presences via region modules and have them be full-fledged presences from the perspective of grid services. This is currently a big stumbling block for implementing client protocols in region modules. There are also LL client dependencies which also make it difficult, or even impossible to create a fully capable grid managed presence in another IClientAPI implementation beside llClientView, so something eventually needs to happen here if anyone wants to get really serious about OpenSimulator supporting other protocol implementations besides the LL protocols. Without such, web-based and other clients are doomed to be second class citizens unless they use a proxy which translates to LL protocols.

On Sun, Aug 16, 2015 at 8:43 PM, Diva Canto <[hidden email]> wrote:
I'm not suggesting getting rid of IClientAPI...
I mean I *wish* we would get rid of it, but that's not what I'm proposing here. I'm just proposing replacing the ad-hoc reflective instantiation of IClientNetworkServer that ClientStackManager is currently doing with a more in-style Region Module.


On 8/16/2015 6:55 PM, Dahlia Trimble wrote:
I like this idea. I have done some physics via the region module interface and had pretty good luck. I've also done client protocol implementations in region modules and I can say that the available interfaces are incomplete for the purposes of the entire LL protocol suite. I use EventManager for tracking scene changes and this seems to work ok for the most part but I don't believe events exist for all events a normal viewer would care about. There is also the issue of managing presences, teleports and region border crossings. I've done some workarounds here but it's not pretty. I suspect a lot of changes to related framework code would need to be done to be successful. I'm also not sure if EventManager events are as efficient and CPU friendly as the direct calls which go thru IClientAPI but I can't say I've seen anything to suggest (yet) that this could be a problem. There are also some efficiency hacks in llClientView and related code (lazy packet initialization for one) which might not easily translate to a region module.

Regardless, it sounds like a good experiment to try :)

On Sun, Aug 16, 2015 at 6:44 PM, Diva Canto <[hidden email][hidden email]> wrote:
We had this conversation today in the IRC about the several plugin mechanisms currently being used by assorted parts of OpenSim. A couple of years ago, we made a big push towards the [new] Region Modules mechanism, and that placed about 95% of simulator plugins in that bandwagon. However, a couple of them are still using their own raw "pluginning," and that makes them hard to (1) explain and (2) distribute as 3rd party packages. They were left behind.

One of them is Physics, the other is the client implementations. I would like to propose that we move these last 2 renegades to the Region Module plugin mechanism, so to reduce entropy and to make them easier to package. From our conversation, moving the Physics plugins to region modules is peaceful. I haven't looked at the client dll yet, but I've been told that people experimenting with other client protocols are using region modules anyway.

This affects the MOSES group developing the PhysX plugin, but it should be straightforward to adjust and it has advantages. Once we move the existing physics plugins to this new mechanism, you should be able to do exactly the same to yours -- the changes aren't that big, and it doesn't affect the Physics interface at all; it's just the way of connecting the physics implementation to the interface. Plus it will make it somewhat easier for you to make your physics plugin available for external testers at intermediate (early) times, if you want.

Any objections?

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev




_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev


_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev



_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reducing the plugin mechanisms

Diva Canto
In reply to this post by Diva Canto
FYI there's now a branch called physmodules that has this work.We'll
have it under testing for some more time, and if no major issues arise,
we'll merge it.

Essentially, all new server-side physics should now be provided as a
region module (INonSharedRegionModule) that also extends PhysicsScene.
See all OpenSim.Region.PhysicsModule.* sub-projects for how to do it. As
region modules, the corresponding dlls need the mono addin declarations
usually placed in AssemblyInfo.cs.

On 8/16/2015 6:44 PM, Diva Canto wrote:

> We had this conversation today in the IRC about the several plugin
> mechanisms currently being used by assorted parts of OpenSim. A couple
> of years ago, we made a big push towards the [new] Region Modules
> mechanism, and that placed about 95% of simulator plugins in that
> bandwagon. However, a couple of them are still using their own raw
> "pluginning," and that makes them hard to (1) explain and (2)
> distribute as 3rd party packages. They were left behind.
>
> One of them is Physics, the other is the client implementations. I
> would like to propose that we move these last 2 renegades to the
> Region Module plugin mechanism, so to reduce entropy and to make them
> easier to package. From our conversation, moving the Physics plugins
> to region modules is peaceful. I haven't looked at the client dll yet,
> but I've been told that people experimenting with other client
> protocols are using region modules anyway.
>
> This affects the MOSES group developing the PhysX plugin, but it
> should be straightforward to adjust and it has advantages. Once we
> move the existing physics plugins to this new mechanism, you should be
> able to do exactly the same to yours -- the changes aren't that big,
> and it doesn't affect the Physics interface at all; it's just the way
> of connecting the physics implementation to the interface. Plus it
> will make it somewhat easier for you to make your physics plugin
> available for external testers at intermediate (early) times, if you
> want.
>
> Any objections?
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Reducing the plugin mechanisms

Diva Canto
FYI this has now been merged with master. There aren't any
configuration, behavioral or API changes; just one single mechanism of
associating features to scenes, rather than many ad-hoc ones. This is
what the architecture looks like at the moment:
http://imagebin.ca/v/2EWADWZSja5w

On 8/31/2015 6:08 PM, Diva Canto wrote:

> FYI there's now a branch called physmodules that has this work.We'll
> have it under testing for some more time, and if no major issues
> arise, we'll merge it.
>
> Essentially, all new server-side physics should now be provided as a
> region module (INonSharedRegionModule) that also extends PhysicsScene.
> See all OpenSim.Region.PhysicsModule.* sub-projects for how to do it.
> As region modules, the corresponding dlls need the mono addin
> declarations usually placed in AssemblyInfo.cs.
>
> On 8/16/2015 6:44 PM, Diva Canto wrote:
>> We had this conversation today in the IRC about the several plugin
>> mechanisms currently being used by assorted parts of OpenSim. A
>> couple of years ago, we made a big push towards the [new] Region
>> Modules mechanism, and that placed about 95% of simulator plugins in
>> that bandwagon. However, a couple of them are still using their own
>> raw "pluginning," and that makes them hard to (1) explain and (2)
>> distribute as 3rd party packages. They were left behind.
>>
>> One of them is Physics, the other is the client implementations. I
>> would like to propose that we move these last 2 renegades to the
>> Region Module plugin mechanism, so to reduce entropy and to make them
>> easier to package. From our conversation, moving the Physics plugins
>> to region modules is peaceful. I haven't looked at the client dll
>> yet, but I've been told that people experimenting with other client
>> protocols are using region modules anyway.
>>
>> This affects the MOSES group developing the PhysX plugin, but it
>> should be straightforward to adjust and it has advantages. Once we
>> move the existing physics plugins to this new mechanism, you should
>> be able to do exactly the same to yours -- the changes aren't that
>> big, and it doesn't affect the Physics interface at all; it's just
>> the way of connecting the physics implementation to the interface.
>> Plus it will make it somewhat easier for you to make your physics
>> plugin available for external testers at intermediate (early) times,
>> if you want.
>>
>> Any objections?
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [hidden email]
>> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>>
>>
>
> _______________________________________________
> Opensim-dev mailing list
> [hidden email]
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
>
>

_______________________________________________
Opensim-dev mailing list
[hidden email]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
Loading...