@ashen-shugar said in The Death Of Telnet: Is It Time To Face The Music?:
@sparks said in The Death Of Telnet: Is It Time To Face The Music?:
You're completely right on the backend side, but I stand by my statement here that most of the front-end UI work needs to be duplicated if you're going to really take advantage of the web. And if the question is why people would want web-only instead of web-and-telnet-both with everything presented in two formats, that duplication of work is the reason I've seen some people balk at that design.
I've been toying with the idea of a form of templating for this.
ergo, a method to have a generic base template code to say 'this is how I want my page to look' and then have the various other languages gobble it up in formatting.
Maybe have it in XML/JSON or something and then allow code to parse it for handling. Could find ways to enbed pre-defined encoding for specific languges as well, so a one template fits all type of environment.
This sounds interesting, but it maybe hard to generalize? There are a slew of templating languages out there though, might be worth looking at over raw xml at least.
The way we on the Evennia side are going about this is to have a generic Python data format internally
("cmdname", (arg,...), {key:value, ...})
For example, a simple send of a description looks like this:
("text", ("A nice place that...",), {})
and the very last protocol layer translate to whichever client type wants the data. Extra info passed with the data are only used by protocols that understand it (so this could also contain instructions pertaining to gui look, window-pane-name etc).
So the protocol layer makes sure the webclient receives a JSON object whereas the telnet client receives a text string or an GMCP/MSDP instruction depending on what it supports. On the web side there is a js lib, in front of which you can put any third party js gui lib you want (our default one mimics a telnet interface).
You could certainly build a single-page js app on top of this that handles bboards, logs etc, but using regular html pages seems more suitable for some of those applications. Since we are built on Django we get the web templating/db-connections for free, but this is then not directly linked to the "traditional" telnet-like output but served by it's own integrated web server. So not quite what you are referring to/suggesting there.
.
Griatch