[u-u] Electronic signage...

Dan Astoorian djast at ecf.utoronto.ca
Wed Jul 13 17:54:52 EDT 2016

On Wed, 13 Jul 2016 13:57:14 PDT, "Greg A. Woods" writes:
> A web browser is the very antithesis of a good solution whenever a
> static form filled with near-real-time data is involved (even ignoring
> the video issue).

I disagree; I can attest that it works quite well for us.  It's not
necessarily the most efficient possible solution, but it doesn't need to
be by any stretch of the imagination.

> Especially when a fully generic browser with full HTML-5 or similar
> support is used for client-side scripting for something that can
> be done directly in the same amount or less of custom code using
> a direct display interface.

Again, it's a question of what you're optimizing for.

> Pure HTML might be more maintainable than custom Python, if indeed all
> that was happening was a static page with auto-refresh, but the same
> cannot be said of the amount of JavaScript that would be required to
> do what Colin was describing.  That's a hairy fur-ball of potentially
> huge impact, never mind being incomprehensible to anyone after a year.

I'm not sure what you think the Javascript would be doing.  At worst, it
might be using a bit of AJAX to update elements of the page; if he used
frames the way I suggested, he wouldn't even need to do that.

> And besides, a static auto-refreshing pure HTML-only page would still
> require some mound of code to generate it -- and instead almost exactly
> the very same amount of code could directly drive the display, so why
> inject yet another custom language (HTML), and massive amount of
> interpreter code (any web browser, even a very simple custom one "just"
> using the massive webkit library)?  An interface library at the level of
> something like Tk would more than suffice.

For one thing, if the content being displayed is being scraped (or even
embedded) from an existing website, generating the HTML may range from
trivial to simple.

Using HTML also makes it more adaptable to other media (e.g., a mobile
web page which displays the same information, in the same layout, sans
video feed).

Hard-coding the layout into a Tk program would be far less flexible than
using a markup language to describe what the display should look like.

(With the infrastructure I set up for my signs, for instance, I can
completely reinvent the layout for all of my signs without even logging
into the Pis.)

Dan Astoorian, Systems Administrator
Engineering Computing Facility
University of Toronto

More information about the u-u mailing list