<div dir="ltr"><div>Awww you had me excited for a moment there....<br><br></div>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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 16, 2015 at 8:43 PM, Diva Canto <span dir="ltr"><<a href="mailto:diva@metaverseink.com" target="_blank">diva@metaverseink.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div><tt>I'm not suggesting getting rid of
IClientAPI...</tt><tt><br>
</tt><tt>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.</tt><div><div class="h5"><tt><br>
</tt><br>
On 8/16/2015 6:55 PM, Dahlia Trimble wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>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.<br>
<br>
</div>
Regardless, it sounds like a good experiment to try :)<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sun, Aug 16, 2015 at 6:44 PM, Diva
Canto <span dir="ltr"><<a href="mailto:diva@metaverseink.com" target="_blank">diva@metaverseink.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
Any objections?<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Opensim-dev mailing list
<a href="mailto:Opensim-dev@opensimulator.org" target="_blank">Opensim-dev@opensimulator.org</a>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a><br>
<a href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev" rel="noreferrer" target="_blank">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div>