<div dir="ltr"><div class="gmail_default" style="font-size:x-small">The power of the board is not really the issue for me. </div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">There are SO many options!</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">I dislike Tomcat and Java-based solutions for many reasons. I have seen many supposedly 'Open' projects fail or just limp along due to poor choice of implementation language. Much of the good SDR software available is crippled by dependence on non-portable code and dependence on proprietary environments such as whatever Microsoft calls <a href="http://dot.net" target="_blank">dot.net</a> this week. Java is a similar island in a world of alternatives.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">You can't keep everyone happy, but the single-board world seems heavily oriented towards Python these days. </div><div class="gmail_default" style="font-size:x-small"></div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">The services need to be coded completely in an Open Source environment that is being taught to end users. There is no need to squander CPU resources and no reason to alienate future maintainers. You can probably write a five line web server in COBOL these days. But who wants to? How do you keep it standards-compliant and secure?</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">I have a long list of personal likes and dislikes of course. I'm cranky and old. But some combinations (language + open libraries + user familiarity) stand out:</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">#1 Python - provides: portability, libraries to talk to hardware, extremely large user base and battle hardened framework support.</div><div class="gmail_default" style="font-size:x-small">#2 node.js - advantages similar to Python, simpler interaction with client-side code (javascript both ends) and efficient low level services.</div><div class="gmail_default" style="font-size:x-small">#3 go / golang - similar to the above, more rigorous language implementation, designed for this type of work, but less well known.</div><div class="gmail_default" style="font-size:x-small">#4 lightweight Web servers such as civetweb (one of many) One example: <a href="https://github.com/civetweb/civetweb" style="font-size:small">https://github.com/civetweb/civetweb</a> - many features, lightweight.</div><div class="gmail_default" style="font-size:x-small">#5 full blown standard web servers: <a href="https://www.nginx.com/resources/wiki/">Nginx</a>, <a href="https://www.apachelounge.com/">Apache</a> + really almost any backend (except Java) - overkill, but extremely well supported, available in any distro, intense security maintenance.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">I do not see much need for complication with more than very lightweight 'frameworks'.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">I would propose an architecture where the localhost runs a simple web service loop. This loop would be launched at boot and principally serve two pages - one page that just provides status information without authentication. The other would be a page requiring login by the owner/controller of the localhost that allows control of services and presentation of data to the owner/controller of the device. All data would be served over secure, certificated connections. All interaction would be through small, purpose-built service handlers that autostart but allow management through the owner/controller's page.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">In many cases, such as the transfer of bulk data to the central repository, connections would be best handled using Web Sockets or some similar mechanism directly by the service process with only lightweight progress reporting directed through the Web interface.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">These are just my thoughts right now, I'm sure that I can come up with more opinions if anyone wants to hear them.</div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small"><br></div><div class="gmail_default" style="font-size:x-small">Dave Witten, KD0EAG</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 3, 2019 at 11:10 AM Engelke, Bill <<a href="mailto:bill.engelke@ua.edu" target="_blank">bill.engelke@ua.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div>
<p class="MsoNormal">Dave – well, my testing has shown the Odroid to have the processing capability of a typical modern desktop (as opposed to a typical SBC like the Raspberry). Be that as it may, could you make a suggestion or two on what to use instead?
-73- Bill<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>From:</b> TangerineSDR <<a href="mailto:tangerinesdr-bounces@lists.tapr.org" target="_blank">tangerinesdr-bounces@lists.tapr.org</a>>
<b>On Behalf Of </b>David Witten via TangerineSDR<br>
<b>Sent:</b> Tuesday, December 3, 2019 10:41 AM<br>
<b>To:</b> <a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a><br>
<b>Cc:</b> David Witten <<a href="mailto:wittend@wwrinc.com" target="_blank">wittend@wwrinc.com</a>><br>
<b>Subject:</b> [TangerineSDR] Webserver for local host<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10pt">All concerned,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10pt">I deeply oppose the use of tomcat and any form of java-based services on the local host. I will not be writing any code to support the use of Java, JSP, or Mono on single-board computers. Almost any other
toolset will do. These are tools rarely used in the single-board computer world. They may be suitable for banks and corporate monoliths (or not!), but not for small systems.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10pt"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10pt">Dave Witten, KD0EAG<u></u><u></u></span></p>
</div>
</div>
</div>
</div>
</blockquote></div>