On 2020-07-24 14:55, Ancor Gonzalez Sosa wrote:
We also discussed the idea of offering a WUI:
- We see real use-cases for it, like:
* configuration via a web browser is kind of common/expected for
embedded systems, IOT devices, etc.
* sysadmins needing to adjust/monitor something when they only have a
browser/tablet/phone at hand
Oh, the old WebUI topic; a zombie that has to be slain every couple of
years, to be summoned back into this world by somebody who hasn't been
part of the previous bloody and messy slaying a few years before... ;-(
I lost count how many times we tried this. I remember some time in 2000
(when I did some experiments based on HTML CGI, again in 2001 by mmj
([*1]), again a year or two later by some intern ([*2]), again years
later with WebYaST ([*3]).
I don't know how much of that still applies with modern web tools (Ajax,
HTML5 and whatnot), but here is a list of challenges that a web UI
(1) Event model. YaST is driven by scripts (Ruby, formerly YCP). At
certain strategic points the script opens a dialog and lets the user
enter data or make decisions. For that, we have an explicit
UI.UserInput() or UI.WaitForEvent() call. This is exactly the opposite
how a web application works: The driving factor there is primarily the
user. A user action initiates a workflow, starts actions, sends off a
form full of data that the user entered.
In previous attempts, this was one of the major problems. This MIGHT
work better today with HTML5 and Ajax and all those tools.
(2) Geometry management. Our YaST UI provides a uniform layout
description to make it look as similar as possible between different UIs
(Qt, NCurses). The abstract layout management widgets on the libyui
level query their concrete implementations about the preferred size of
each sub-widget on each level, add up the totals, and manage excess or
missing screen space. To do that, the concrete widget has to know things
about its font metrics and the size (in whatever unit!) that the widget
needs on the screen. But that concept does not exist in a web UI
(AFAIK); there is no way of knowing how many pixels any given text will
need in width and in height. This is why web designers love to introduce
fixed limits for their content: The base page is designed to fit into,
say, 800 pixels horizontally, and if you have more than that, you will
get more empty space on the side. But the browser can (and will) scroll
endlessly in the vertical dimension.
This is just not how our UIs work. Trying to hammer a web UI into shape
for that will make it look like those poorly designed flash applications
of the early 2000s (anybody remember that crap? Always too tiny fonts,
always too small on some screens, and not fitting on others?).
(3) You can only support a limited number of browsers; they are just too
different to do anything else. Most web apps start with determining what
browser the user has, and they have a ton of library code for the quirks
and limitations of the most widely-used ones.
Realistically, that means they will only run well on the most recent
versions of Chrome and Firefox, maybe also Safari. Different screen
sizes / resolutions on mobile devices are already a challenge. You want
your content to fit on the screen, yet you want to use fonts that the
user can actually read (and the fact that most web designers are young
have good eye sight and love tiny fonts doesn't help either).
That means you need to come up with a set of different layouts for
different purposes: Normal PC screen, smartphone, tablet; not to mention
HiDPI screens and special layouts for visually impaired users (or
somebody might sue you based on some obscure Delaware law). Good luck
testing all that stuff. Good luck maintaining it.
(4-97) ...there are more, I am sure. Those are just the few that come
from the top of my head.
(98) There be dragons.
(99) RFC 1925 section 3: With sufficient thrust, pigs fly just fine. ;-)
[*1] Mads Martin Joergensen, a legend of the SuSE of old. When he had
freshly arrived from Denmark and was on transit to the newly founded
SuSE USA, he brought up that topic of a YaST web UI again. Somebody had
told him that I had tried tis before, so he asked me what I would do. I
said "I'd jump right out of the window to be put out of that misery",
and he started laughing; only when he saw that I was not laughing at
all, he realized that I was not joking. I was dead serious.
[*2] I don't remember that guy's name; only that he was very convinced
of himself, and also convinced that we old farts were just too stubborn
and too unflexible to try such a novel thing. But he ruled the world, so
he'd show us how to do that right. He began a very enthusiastic project,
but after a while it just fizzled out with a gazillion problems. He
wouldn't listen to us old farts who told him about the problems in
advance; but of course we were just too stupid and too lazy to do it
[*3] Anybody remember WebYaST? IIRC that was a very basic web UI that
more or less executed YaST command line calls when the user had
completed entering data into a form and would send that form off. Not
really anything that I would call a UI on the same level as our other
UIs (Qt, NCurses, even Gtk).
Stefan Hundhammer <shundhammer(a)suse.de>
SUSE Linux GmbH
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: yast-devel+owner(a)opensuse.org