[TangerineSDR] Webserver for local host

David Witten wittend at wwrinc.com
Tue Dec 3 13:51:33 EST 2019


Bill,

I haven't played with flask in a while, but I'm sure it must work.  I
completely agree about Py3 v Py2.  Py2 is over.  Anything that isn't ported
over is mostly dead.

Dave

On Tue, Dec 3, 2019 at 12:39 PM Engelke, Bill <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>
> *Sent:* Tuesday, December 3, 2019 12:17 PM
> *To:* Engelke, Bill <bill.engelke at ua.edu>; Evan <em328 at njit.edu>;
> 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 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> 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> *On Behalf Of *David
> Witten via TangerineSDR
> *Sent:* Tuesday, December 3, 2019 10:41 AM
> *To:* tangerinesdr at lists.tapr.org
> *Cc:* David Witten <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/tangerinesdr_lists.tapr.org/attachments/20191203/832e886b/attachment-0001.html>


More information about the TangerineSDR mailing list