[TangerineSDR] Webserver for local host

[John Ackermann N8UR]

I've been learning Python over the last few months, and decided to start
with version 3 to be all cool and modern.  I'll spare you the pain I've
gone through trying to deal with its nature as an "untyped except when
it wants to be" language and just say that with the major changes
between Py2 and Py3, I think using only one version in a project is a
very good idea, and despite the pain, Py3 is the one to go with.

But I still like perl a lot better for text handling!

John
----

On 12/3/19 1:49 PM, Markowitz, Evan via TangerineSDR wrote:
> Hi Bill,
> 
> Flask supports Python 3.5+, and I've used it across all of those
> versions up to and including 3.8 with no problem.
> 
> If we can, I'd love to be exclusive to Python 3 as, like you mentioned,
> Python 2 is going to be unsupported in less than a month anyway.
> 
> Thanks,
> Evan
> 
> 
> On Tue, Dec 3, 2019, 1:39 PM Engelke, Bill <bill.engelke at ua.edu
> <mailto:bill.engelke at ua.edu>> wrote:
> 
>     Hello Dave & Evan –____
> 
>     Let’s gravitate toward Python then.  The framework that Evan
>     mentioned (Flask) does seem to be of a lightweight variety, and
>     should allow us to implement all the screens we need for controlling
>     the TangerineSDR.  (I have attached the latest version of the
>     Detailed Design for what is planned to run in the SBC for review and
>     comment.  My idea is to implement all the web screens in the spec
>     using whatever framework we pick).____
> 
>     __ __
> 
>     One question, to try and avoid “interdependency hell” – the latest
>     GNUradio runs well with Python V3.6.9. (I’m hoping we can avoid
>     using Python2, as I have seen a continuous feed of warnings that
>     support is phasing out).   I hope that Flask plays nice with Python3
>     (??)____
> 
>     __ __
> 
>     All feedback is most welcome… 73- Bill AB4EJ____
> 
>     __ __
> 
>     __ __
> 
>     *From:* David Witten <wittend at wwrinc.com <mailto:wittend at wwrinc.com>>
>     *Sent:* Tuesday, December 3, 2019 12:17 PM
>     *To:* Engelke, Bill <bill.engelke at ua.edu
>     <mailto:bill.engelke at ua.edu>>; Evan <em328 at njit.edu
>     <mailto:em328 at njit.edu>>; tangerinesdr at lists.tapr.org
>     <mailto:tangerinesdr at lists.tapr.org>
>     *Subject:* Re: [TangerineSDR] Webserver for local host____
> 
>     __ __
> 
>     The power of the board is not really the issue for me.  ____
> 
>     __ __
> 
>     There are SO many options!____
> 
>     __ __
> 
>     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 dot.net <http://dot.net> this week.  Java is a
>     similar island in a world of alternatives.____
> 
>     __ __
> 
>     You can't keep everyone happy, but the single-board world seems
>     heavily oriented towards Python these days.  ____
> 
>     __ __
> 
>     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?____
> 
>     __ __
> 
>     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:____
> 
>     __ __
> 
>     #1 Python - provides: portability, libraries to talk to hardware,
>     extremely large user base and battle hardened framework support.____
> 
>     #2 node.js - advantages similar to Python, simpler interaction with
>     client-side code (javascript both ends) and efficient low level
>     services.____
> 
>     #3 go / golang - similar to the above, more rigorous language
>     implementation, designed for this type of work, but less well known.____
> 
>     #4 lightweight Web servers such as civetweb (one of many)  One
>     example: https://github.com/civetweb/civetweb - many features,
>     lightweight.____
> 
>     #5 full blown standard web servers: Nginx
>     <https://www.nginx.com/resources/wiki/>, Apache
>     <https://www.apachelounge.com/> + really almost any backend (except
>     Java) - overkill, but extremely well supported, available in any
>     distro, intense security maintenance.____
> 
>     __ __
> 
>     I do not see much need for complication with more than very
>     lightweight 'frameworks'.____
> 
>     __ __
> 
>     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.____
> 
>     __ __
> 
>     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.____
> 
>     __ __
> 
>     These are just my thoughts right now, I'm sure that I can come up
>     with more opinions if anyone wants to hear them.____
> 
>     __ __
> 
>     __ __
> 
>     Dave Witten, KD0EAG____
> 
>     __ __
> 
>     On Tue, Dec 3, 2019 at 11:10 AM Engelke, Bill <bill.engelke at ua.edu
>     <mailto:bill.engelke at ua.edu>> wrote:____
> 
>         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____
> 
>          ____
> 
>         *From:* TangerineSDR <tangerinesdr-bounces at lists.tapr.org
>         <mailto:tangerinesdr-bounces at lists.tapr.org>> *On Behalf Of
>         *David Witten via TangerineSDR
>         *Sent:* Tuesday, December 3, 2019 10:41 AM
>         *To:* tangerinesdr at lists.tapr.org
>         <mailto:tangerinesdr at lists.tapr.org>
>         *Cc:* David Witten <wittend at wwrinc.com <mailto:wittend at wwrinc.com>>
>         *Subject:* [TangerineSDR] Webserver for local host____
> 
>          ____
> 
>         All concerned,____
> 
>          ____
> 
>         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.____
> 
>          ____
> 
>         Dave Witten, KD0EAG____
> 
>