<div dir="ltr"><div><div dir="ltr" style="font-family:arial,sans-serif;font-size:13px"><div><br></div><div><div><div>I believe the web introspection thread highlights the tradeoffs of usability and interoperability with performance and efficiency, as discussed previously wrt usability:</div>
<div> </div><div><div class="gmail_extra">  <a href="http://lists.ros.org/pipermail/ros-users/2014-February/068247.html" target="_blank">http://lists.ros.org/pipermail/ros-users/2014-February/068247.html</a></div></div><div>
<br></div>William, you are correct about native apps if the use case is restricted to a root-access machines running a specific OS an a LAN, connecting to a LAN over VPN, or similar specifically-optimized configuration.  Recent history shows that such system and network optimizations in ROS have come at a cost in terms of ease of use, modification, build, and deployment.  <div>
<br></div><div>Using customized messaging over a non-HTTP transport will surely yield significant performance benefits.  However, this will come at the cost on the front-end with respect to usability, accessibility beyond a LAN, and interoperability across different development frameworks, etc.  While I agree JavaScript and HTML5 has a lot of great frameworks coming up, it is important to acknowledge the ways such frameworks restrict extensibility and interoperability, especially the potential for breaking code built on these frameworks over time.</div>
<div><br></div><div>I believe William's message acknowledges this tradeoff.  It is just good to clarify the relative strengths and weaknesses of different design choices with a broader range of use cases in mind.</div>
<div>___</div><div>Chad</div></div><div><br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>------------------------------<br><br>Message: 5<br>Date: Wed, 25 Jun 2014 13:27:28 -0700<br>From: William Woodall <<a href="mailto:william@osrfoundation.org" target="_blank">william@osrfoundation.org</a>><br>To: User discussions <<a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a>><br>
Cc: User discussions <<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a>><br>Subject: Re: [ros-users] Web introspection tools<br>Message-ID:<br>        <CAFe2DWid9H+zWwou+YTBy9ABBxOzVf7ckG3=<a href="mailto:kWrJ1fZ3noTEBQ@mail.gmail.com" target="_blank">kWrJ1fZ3noTEBQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br><br>I haven't tried to implement anything, but my guess is that at least for<br>rviz, there are several places where a native app would out perform the web<br>version considerably. For example, transforming data between frames before<br>
visualizing would likely be very intensive in javascript. You could push<br>most if not all of this into the server side which could be C++, but then<br>you run into the fact that websockets actually introduce considerable<br>
overhead to communication when compared with ROS topics. This makes it a<br>bottleneck, for example the robotwebtools have things like the tf<br>republisher which takes /tf data and does some tricks to reduce the number<br>
of messages sent. I believe this was developed because the websockets<br>couldn't keep up with /tf. I don't think the JSON data is the only reason<br>for increased bandwidth usage, but also the fact that it must go over http<br>
requests.<br><br>I'm sure about the custom shaders being available or needed, but I imagine<br>that the lack of them would make rendering things like pointclouds much<br>less efficient.<br><br>For other tools like rqt_graph, rqt_topic, and other things I think the web<br>
based tools make a lot of sense. You can work around access to local files<br>using the server for files on the target machine and you can access files<br>local to the browser's machine using html5 and javascript in some cases.<br>
There are some awesome up and coming javascript libraries for data<br>visualization like <a href="http://d3js.org/" target="_blank">d3js.org</a>, which we have done some experimenting with<br>here at OSRF.<br><br>--<br><br>
<br>On Wed, Jun 25, 2014 at 1:05 PM, Vincent Rabaud <<a href="mailto:vincent.rabaud@gmail.com" target="_blank">vincent.rabaud@gmail.com</a>><br>wrote:<br><br>> At ROS Kong, some rQt on the web was demoed as well as a Gazebo web<br>
> visualizer.<br>><br>> I am no expert in web programing but what prevents us from moving rQt and<br>> RViz to the web/javascript ? The obvious advantages would be cross-platform<br>> support, optimizations independent of the underlying libraries, easier code<br>
> to debug, no compilation. Plus, there are already great tools like<br>> robotwebtools and rosbridge.<br>><br>> Here are a few reasons I was told that could prevent that move; are those<br>> really valid ? Are there better reasons ?<br>
> - hard to access local files (html is not aware of local files)<br>> - no customizable shaders in WebGL (is that the case ? do we need those ?)<br>> - slow JSON parsing libraries (aren't those optimized in recent browsers ?)<br>
> - heavy bandwidth usage (how about binary JSON ?)<br>><br>> _______________________________________________<br>> ros-users mailing list<br>> <a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a><br>
> <a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>><br>><br><br><br>--<br>William Woodall<br>ROS Development Team<br><a href="mailto:william@osrfoundation.org" target="_blank">william@osrfoundation.org</a><br>
<a href="http://wjwwood.io/" target="_blank">http://wjwwood.io/</a><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <<a href="http://lists.ros.org/pipermail/ros-users/attachments/20140625/b1b518c9/attachment-0002.html" target="_blank">http://lists.ros.org/pipermail/ros-users/attachments/20140625/b1b518c9/attachment-0002.html</a>></blockquote>
</div></div></div></div></div>