[u-u] Electronic signage...

[Eric Siegerman]

I'm on the HTML side.  It pisses me off that web apps have taken
over the world -- that's a rather icky platform to write for --
but for what you're talking about, it seems a very good choice.

One of the problems has been browser-compatibility issues.  I
have the impression (*not* backed up by experience) that things
have improved on that score; but even if they haven't, it's a
non-issue for your application, since you get to specify the
browser and version.


On Thu, 14 Jul 2016 11:55:12 -0400, Colin McGregor
<colin.mc151 at gmail.com> wrote:
> Finding someone to carry this
> project forward from within the volunteer talent pool of a sailing
> club will then become the issue.  Which will be easier to find,
> someone who knows HTML or Python?

False dichotomy :-)  I'd suggest using HTML *and* Python.  Or
maybe Ruby or PHP.

Reasons:
 - Anything interpreted and memory-managed is going to be easier
   for you to write, and for your successors to maintain, than C
   is
   
 - Down the road, I believe you'll be far more likely to find
   someone who knows those languages than a C programmer.  (And
   even if they know a different one of the three than you used,
   the learning curve will be easier for them than going from any
   of them to C.)

I have a personal preference among them, but reasonable people
can differ.  ('Nuff said about that; if I go into detail, it'll
be flamewar bait....)

(Perl would also be a good technical fit, but it's pretty
trailing-edge at this point -- popularity is low and getting
lower -- so it's not a great choice from a future-handover point
of view.)


In terms of the overall architecture, if I were building this
thing, I'd write a bunch of little Python (or whatever) scripts
for data collection/translation/formatting (as opposed to one big
hairy program).

Run them from cron -- not sure who said that, but yeah!  (Unless
in a given instance, it makes more sense to make a collector a
single long-lived process.  Not sure why that might be, but there
might be a reason.)

As for turning the collected data into a web page:
  - you could do the AJAX thing, using Javascript to slurp in the
    saved data

  - or (and here's where my own old-school biases start to show
    :-)), a low-tech approach would be to have another cron job
    that just spits out a static HTML page, which the browser
    then periodically refreshes from

  - or use Dan(?)'s IFRAME idea.  Actually, I think I like this
    the best.  Simple, clean, and changing the layout doesn't
    involve code, only editing the master HTML file.  Plus, it'll
    probably be the easiest way to deal with the video feed from
    the camera

The choice you make here will inform the decision as to whether
the data-collector scripts should write their output as HTML
fragments or simply data (JSON, XML, CSV, YAML, or whatever).

Sounds like a fun little project.

  - Eric