<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><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><tt><br>
      </tt><br>
      On 8/16/2015 6:55 PM, Dahlia Trimble wrote:<br>
    </div>
    <blockquote
cite="mid:CAAQTD4WfRhOPmXYFcG=pCvtbM2F1VLJcD_3cdmEUzK52vyrO0A@mail.gmail.com"
      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 moz-do-not-send="true"
              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 moz-do-not-send="true"
              href="mailto:Opensim-dev@opensimulator.org"
              target="_blank">Opensim-dev@opensimulator.org</a><br>
            <a moz-do-not-send="true"
              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 class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@opensimulator.org">Opensim-dev@opensimulator.org</a>
<a class="moz-txt-link-freetext" href="http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev">http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>