[TangerineSDR] Webserver for local host

[David Witten]

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/1ca55ecd/attachment.html>