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 faces: (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. ;-) https://tools.ietf.org/html/rfc1925 [*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 right. [*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). Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org