A new platform?
-
There's also been other similar alternatives (though I don't know how easy they are to set up), which I always find funny as they are perfect for the games that want 'locations only' and not a full grid. Things like DigiChat, which tons of WoD games run on as well.
-
@ashen-shugar said in A new platform?:
Some learning of new things is expected. So how about we lay that expectation on others and not trying to dumb it down so much it becomes repulsive to everyone else?
I agree with this. As the person who mentioned it, however, I think there are reasonable limits to that, too.
People having an expectation that someone will go learn three or more programming languages to make one aspect of a project or they're lazy is as absurd and obnoxious as 'I don't want to have to learn anything'.
I wanted a skin for mediawiki that does specific things. This meant tinkering with javascript, LESS (while similar to CSS, different in non-trivial ways), and PHP -- none of which I'd ever touched or even looked at before. It also meant knowing how to trawl through the guts of mediawiki to find obscure system messages and determine what was doing what, what could go, what was essential, and so on. Mediawiki can be a giant clusterfuck, being a project with thousands of authors, all with their own ways of doing things. They're attempting to standardize a few things, but they're doing it in a piecemeal way that means you need to know the old way and their new way because things are only half converted at this time, and the new way isn't terribly well-documented. ("X is deprecated in favor of Y." "Y: <blank space, cricket noises, sometimes a polite note that documentation is coming that was left over a year ago...>" <-- this is really a thing, and it's not uncommon.)
While frustrating, I didn't really have an issue with that. I had to kitbash a lot of crap to make it do things the way I wanted in ways that I'm sure someone else would scratch their head over, too, but, hey, it worked and only needed a few tweaks to get it where I wanted it when I threw in the towel on dev. It wasn't a small amount of work. Maybe it would have been for someone who knows what they're doing, but I promise you, that person is not me, because I had to be an adult (read: google all the things ever) and figure everything out one tiny piece at a time.
If a player came to me with the expectation that I should be obligated to do that because that's how they wanted it, I would probably have told them to go fuck themselves. Similarly, if I have code requests, I try to break them down to the barest bones of 'this is what I need to do X' that I can later tweak as needed, if needed.
-
@faraday said in A new platform?:
Not effectively though. You can do a basic web client, but to do more advanced integrations requires a more advanced interface. Just shipping commands like "WHO" to the game and trying to parse ASCII text back out is not going to get you very far.
The MUSH can send JSON (in addition to ASCII) for out of band communication with web clients. It's as easy as adding wsjson(object) to the end of your @pemit. It is only sent to web sockets so you don't have to worry about hiding it from telnet connections.
-
@grapenut That’s cool but my general point was that you have to go implement all that from scratch. Existing commands like +who and page and +finger don’t do JSON intrinsically (right?).... and is there a way to send JSON commands //to// the game?
-
@faraday said in A new platform?:
@grapenut That’s cool but my general point was that you have to go implement all that from scratch. Existing commands like +who and page and +finger don’t do JSON intrinsically (right?).... and is there a way to send JSON commands //to// the game?
Building and sending JSON data strings is trivial though. The hard part is doing something useful with it on the client. What each game chooses to display and how is going to be different for every game, so it needs to be implemented from scratch anyway. A +who side panel in the browser could be something like an angular.js list and you just feed it an array of player data that you build at the same time as you are @pemitting it to the terminal. Same thing for a +sheet or a map, etc.
As for sending JSON commands to the MUSH there's really no need and implementing a parser wouldn't be worth it. It's just formatted text so you might as well send it as regular text commands.
-
@grapenut said in A new platform?:
Building and sending JSON data strings is trivial though.
For a single command, sure it's not so bad, but if you wanted to convert one of the existing code suites like mine or Volund's? It would be a massive undertaking.
@grapenut said in A new platform?:
As for sending JSON commands to the MUSH there's really no need and implementing a parser wouldn't be worth it. It's just formatted text so you might as well send it as regular text commands.
Except that then limits the web client to implementing only what you can do with regular text commands. For example - you couldn't do something like a character directory, because there is no single "get me a list of all characters" command. (You'd have to add one.)
Also websockets are useful, but a bit unreliable for the basis of a robust web implementation.
Just to be clear - I agree with you that you can make a web client with PennMUSH given enough time and effort. All I'm saying is that I don't think you can make "the same sort of web portal" as you said earlier. The interface limits what you can do.
-
@faraday said in A new platform?:
For a single command, sure it's not so bad, but if you wanted to convert one of the existing code suites like mine or Volund's? It would be a massive undertaking.
Yes, somebody will have to do some work to implement a new thing. Putting data into a JSON object and sending it is not the hard part though. It's a simple extra softcoding task that's less complicated than the @pemit part of a command. One person could implement it for yours or Volund's code suites and then it would be done for everybody. The hard part is figuring out what data to send and how to display it in the browser.
Except that then limits the web client to implementing only what you can do with regular text commands.
JSON is sent as a string. Whatever complex information you would want to format into a JSON object can just as easily be formatted as a +command that=has=multiple=arguments. If you really want to send commands as JSON you can make a { command that parses it, but then you still need to implement individual handlers on the MUSH for different objects and commands. It's easier to just use the regular command interface that we already have implemented, with perhaps an additional low level version of some complicated +commands that accept multiple arguments at once.
For example - you couldn't do something like a character directory, because there is no single "get me a list of all characters" command. (You'd have to add one.)
The client can send a think command with whatever softcode to generate an arbitrary JSON list of players, e.g.
conn.send('th wsjson(\{"playerlist": [[iter(lsearch(all,type,player),"%i0",,\,)]]\})')The only difference is that the display is event-driven instead of inline, but that's the standard paradigm for browser user experience anyway.
Also websockets are useful, but a bit unreliable for the basis of a robust web implementation.
It's as reliable as your telnet connection to the MUSH. You need to be connected and authenticated to exchange useful data, but reconnecting is handled automatically in the background whenever the connection is lost. It's no more or less reliable than using an API key to grab some data from a google API.
Just to be clear - I agree with you that you can make a web client with PennMUSH given enough time and effort. All I'm saying is that I don't think you can make "the same sort of web portal" as you said earlier. The interface limits what you can do.
I disagree. The only limit is that nobody has done it yet. I commend Ares and Evennia for tackling this problem. My original comment was only to say that PennMUSH (and RhostMUSH too) can be retrofit to have a similar web portal interface if someone with web developing skills is interested. It can be done in parallel with the existing telnet interface to support both types of users.
-
@grapenut said in A new platform?:
It's as reliable as your telnet connection to the MUSH.
No, it really isn't, and there are a ton of articles on the web like this one explaining why. Websockets require a lot of fallback layers to implement properly across different browsers and versions, and are prone to significant firewall issues.
@grapenut said in A new platform?:
Whatever complex information you would want to format into a JSON object can just as easily be formatted as a +command that=has=multiple=arguments.
Again, no it can't. There's a reason JSON as a structured parsing language has overtaken other homegrown string parsers, because it addresses countless issues like nested quotes and whatnot.
I applaud you/whomever for attempting to retrofit web capabilities onto older MU servers for those who want to use it. That's a positive. But arguing that a cobbled-together "think wsjon()" thing over web sockets is equivalent to a first-class dedicated JSON API flies in the face of every good programming practice I know.
-
@faraday said in A new platform?:
No, it really isn't, and there are a ton of articles on the web like this one explaining why. Websockets require a lot of fallback layers to implement properly across different browsers and versions, and are prone to significant firewall issues.
Websockets work great for what we are doing. We don't have the same requirements or fault tolerances as an enterprise website doing financial transactions, for instance. If your command doesn't get through because the connection died, the command is sent again after reconnecting. It is subject to the exact same firewall and proxy issues as your telnet connection, and I probably won't lose too much sleep if it doesn't work perfectly on IE9.
Again, no it can't. There's a reason JSON as a structured parsing language has overtaken other homegrown string parsers, because it addresses countless issues like nested quotes and whatnot.
JSON is just plain text. A command is just plain text. Specifics of JSON parser implementations aside, regular commands allow you to easily reuse all the same server-side code you've already written. What kind of data do you envision needing to be sent to the server from a web client that absolutely must be in a JSON object, and how would you allow telnet users to achieve the same functionality while only using standard commands?
I applaud you/whomever for attempting to retrofit web capabilities onto older MU servers for those who want to use it. That's a positive. But arguing that a cobbled-together "think wsjon()" thing is equivalent to a first-class dedicated JSON API flies in the face of every good programming practice I know.
I just cobbled together a quick softcode example for how to do what you asked from the browser. There is a first-class JSON API in PennMUSH for building the objects with proper formatting and escaping. I would absolutely recommend making a dedicated command for triggering an event like that rather than trying to cobble it together on the fly, but you asked.
I'm not trying to say what you've done with Ares was easy, or that making a web portal for PennMUSH wouldn't be a lot of work. There isn't a web portal built for PennMUSH yet exactly because it is a lot of work. To suggest that it's impossible because it would be hard or because the network protocol is somehow limited is a mistake though.
-
@grapenut I've already seen several people having serious issues playing via websockets because of browser or firewall issues, so it is absolutely not as reliable as telnet even in a low-impact environment like a MUSH.
Anyway, I never said it was impossible to build a web portal in PennMUSH, I said it was not the soundest technical approach and false to equate it with a robust and dedicated JSON API. But best of luck to you regardless.
-
@faraday said in A new platform?:
Anyway, I never said it was impossible to build a web portal in PennMUSH, I said it was not the soundest technical approach and false to equate it with a robust and dedicated JSON API. But best of luck to you regardless.
Sorry. I didn't mean to suggest that Penn's economy-class JSON API was in any way equitable to Ares' robust and dedicated first-class JSON API. Thanks for your kind wishes I guess?
-
As for the reliability of websockets, the main issues we've seen had been on the game runner side, when not setting it up correcty. But yes, some people do have firewall or browser issues occasionally.
In the Evennia case we use a two-pronged approach for this - if the web client's websocket connection fails or times out the web client transparently falls back to using old-style COMET long-polling. Haven't found any browsers having issues with that combination so far. Not sure if Penn has anything like that on the Server side, but it can all have the same API so you don't need to worry about which type of connection was actually negotiated in the end.
.
Griatch -
@faraday said in A new platform?:
@grapenut I've already seen several people having serious issues playing via websockets because of browser or firewall issues, so it is absolutely not as reliable as telnet even in a low-impact environment like a MUSH.
Anyway, I never said it was impossible to build a web portal in PennMUSH, I said it was not the soundest technical approach and false to equate it with a robust and dedicated JSON API. But best of luck to you regardless.
Not to be a parade rainer, but just like Python, Ruby, and Perl have modules for full, robust, and dedicated JSON API's, so does C.
It's just a matter of including the library class and a quick modify to use it as a built in function handler. If I could get my lazy arse interested I could probably do it in a few hours, but meh. Not on my high list of important tasks in this point of time.
The thing though is it's very possible to do it.
As for importing and exporting existing softcode in JSON?
Assume we have json_encode() and json_decode() on a Rhost.
@wipe me/json;@pipe/on json;+pretty FS3 command here;@pipe/off;think [json_encode(v(json),args-go-here)]And do that via an external liburl call and you have a full web based JSON handler for the arguments. Since all the output of the command is stored in an attribute, any and all transformation can be done on the fly, anyway you want, before, after, or during json transformation.
I honestly don't see the difficulty? Am I missing something?
-
@griatch said in A new platform?:
In the Evennia case we use a two-pronged approach for this - if the web client's websocket connection fails or times out the web client transparently falls back to using old-style COMET long-polling. Haven't found any browsers having issues with that combination so far
That's why you don't see issues - because you've fallen back to not using websockets when they fail and/or are unavailable. A purely websockets-based solution is not reliable.
@ashen-shugar said in A new platform?:
I honestly don't see the difficulty? Am I missing something?
I'm not sure what you're trying to demonstrate with the pipe thing. What @grapenut showed makes sense... if you tack on JSON output to the end of, say, +finger, then you can parse that on the webclient side:
&cmd-+finger:think pemit(%#,ALL KINDS OF ASCII JUNK)[wsjon(finger: { name: [name(%0)], position: [xget(%q0,position)], etc. })]But to implement that for every softcode command would be a giant and painful undertaking, and I'm not sure how you'd handle the hardcoded commands like pages and channels. Sending input with
{ to: [ list, of players ], subject: "Subject", message: "Some message }and trying to convert that to+mail names=subj/messageagain sounds like a lot of work and kinda messy.Basing a web API on +-commands or the website trying to send
think [wsjson(stuff)]sent over websockets just isn't an approach I'd advocate, that's all. If somebody wants to do it, then yes - of course - it's technically possible.ETA: On a more positive note though - if you isolated the JSON stuff in a separate set of commands, like website/profile, website/scenes, etc. that JUST did JSON, then I don't think it would be quite so bad. You wouldn't need to have the website send softcode, you wouldn't have to center the web interface around existing MUSH commands, and you wouldn't need to kludge ASCII and JSON together. You still have the websocket/input/hardcoded command issues, but it's better than nothing.
-
@faraday said in A new platform?:
@griatch said in A new platform?:
In the Evennia case we use a two-pronged approach for this - if the web client's websocket connection fails or times out the web client transparently falls back to using old-style COMET long-polling. Haven't found any browsers having issues with that combination so far
That's why you don't see issues - because you've fallen back to not using websockets when they fail and/or are unavailable. A purely websockets-based solution is not reliable.
Well yes, that's why I pointed out a way that has worked very reliably for us. I doubt a solution like that would be impossible to implement in Penn on the server level?
.
Griatch -
@griatch said in A new platform?:
Well yes, that's why I pointed out a way that has worked very reliably for us. I doubt a solution like that would be impossible to implement in Penn on the server level?
Sorry I might have misread what you said then. I agree.
Also @grapenut @Ashen-Shugar -- I'm not meaning to disparage the custom APIs on Penn/Rhost so apologies if it came across as overly negative. It's a good step forward for the platform and I hope people take advantage of it.
All I was trying to say is that from a purely technical perspective, I think a JSON-based API over pure HTTP is more robust, well-structured and extensible than a websocket interface piggybacking on existing softcode commands. I would love to see somebody implement the former sort of API for the old servers.
Until they do, though, I think a statement that "you can do the same sort of web portal" with Penn that you can do with Evennia/Ares is a bit misleading. Yes, you can build a website for Penn but the amount of work involved is orders of magnitude different.
-
As of last night Raevnos pushed the SQLite branch to master which means PennMUSH has the json_query() and json_map() functions for parsing JSON strings. The code for PennMUSH to receive JSON data is already there but not hooked to anything, so it should be a quick fix to allow Penn to receive JSON and pass it to a handler.
The website never needs to send softcode, that was just an example. For a lot of things, you will want dedicated commands that are just used by the website to generate a JSON response that don't have a terminal equivalent (e.g. context menus, player lists, etc). But for something like a +finger or +who you can show the standard text in the terminal, show a popup version with links and images on the side, embed links and images directly in the terminal text, or some combination of the 3.
