I have been playing around with trying to update the enCore Xpress user interface.
"Trying" is the key word here.😑
First a little background on why this is something to even worry about.
The user interface and many of the more useful utilities included in the Xpress system are "frames based" layouts. Frames are a way to split a webpage up into independent pieces each with their own URL and context. This is a 1990's technology, a solution for the problem of how to include other web resources inside a webpage, that retained all the formatting, and allowed easy update of a piece without disturbing the rest of the page etc. The frame was basically a window in which to display content from somewhere else.
Practically its main use in the days before CSS and JavaScript was to keep a menu of links available even as the main content frame changed. Since loading a new page always caused the page to reload completely keeping state information was tricky and necessitated a bunch of cookies and other fragile data structures. Now as far as Xpress is concerned frames were the perfect vehicle to enable the simple web server running inside the MOO to display easily. Each frame was a way to display the output of a MOO verb. Because frames could reference each other easily it was possible to maintain state through logged in session and update the display as required.
Now frames have always been controversial because they break some of the fundamental attributes of the Web. Things like search engine indexing, bookmarking, and even the "back" button on the browser.
Want to get treated like a pariah in web development circles?
Ask about how to setup something using frames!
AJAX, which used JavaScript and XML data, was a way to do part of what we need. I experimented with it in my AJAX auto updating room back in 2011. It allowed the web page for a room or object to automatically update the list of objects contained as it changed without having to do a "look" to refresh the web display. But AJAX causes a lot of traffic to the MOO web server, it essentially polls the object looking for changes. Since unlike the formal web server running alongside the actual MOO executable, the in-moo web server can impact the lag that a user experiences. When it is creating and updating the display NOTHING ELSE CAN RUN. I considered this a reasonable trade off since it only happens when a room is actually being displayed. However to use it for the Xpress interface itself would entail constant polling from every connection, from every frame of the interface, all the time! Maybe OK for one or two users but would kill a system like Literary Worlds which quite happily handles 100 or more users at once with the current frames based interface.
Definitely not an optimal solution to get rid of the frames.
So...
For our purposes using enCore, FRAMES ARE PERFECT! Now that we no longer need the JAVA applet to connect we have a pure web based application I.E. a Web App! Web apps are a different critter entirely from a typical webpage. For one thing Google doesn't ever get to index the inside chunks of a web app display, nobody bookmarks parts of a web app, and the browser's back button doesn't work in a web app like it does on a typical webpage anyway.
Notice that these are the main complaints that the web development community had about frames!
If you look at how typical web apps are coded you'll see a tremendous amount of complexity, and therefore fragility, needed just to do what Xpress does with a simple frameset document.
I'm a big fan of 'if it isn't broken don't fix it' so I wouldn't mess with Xpress except for one thing...
Frames are no longer included in HTML5, not just "deprecated" but
actually gone! While most browsers still know how to display them that
may not continue. Already support for frames is beginning to disappear
in mobile browsers. This means that if we want to continue to keep enCore and its Xpress interface working we should, reluctantly, see about changing the interface away from frames.
So far my initial messing around has been very discouraging. In the next parts of this series I will try to explain what I've tried and what worked and what didn't.
Thanks for reading.
Part II is here.
