@thenomain said in How much Code is too much Code?:
But then, I spend way too long coding even the simplest thing.
This.
This right here is what I and others have spent a horrible amount of time in Rhost to help with.
We made dev-end tools to give people more options to work outside of MUSH to do so.
These tools are:
- @doors -- A method to estabish a TCP/IP connection from within the game to an outside source.
Pros:
- It is a simplistic interface to allow any TCP/IP connection.
- It allows async connectivity so you can mush while connected to the external application
- It allows a fairly unlimited number of connections to external services
- It comes standard with a MUSH/MUD/MOO door
Cons:
- It uses TCP line mode and not character mode
- You have to write your own TCP/IP interface for each connection you want
- You have to know C code to write your connection interface
@DOOR
Command: @door
Switches: STATUS, OPEN, CLOSED, LIST, PUSH, KICK
@door provides control over arbitraty TCP connections that are opened from
inside the mush to some external program or service.
In order for a door to be available a C-code module must first be loaded by
an Admin(*), or compiled statically into the mush server.
To see what doors exist on your system, type: @door
(*) Not available in RhostMUSH 3.2.4p15 and earlier.
See 'DOOR SYNTAX' on a quick listing of commands and what they do.
See Also: DOOR_OPEN, DOOR_PUSH, DOOR_CLOSE, DOOR_LIST, DOOR_STATUS,
DOOR_KICK, DOOR_WRITING, INTERNAL_DOORS, DOORED, DOOR SYNTAX
- execscript()
Execscript allows you to call an external application, script, binary, or anything else, regardless of the language it is written in, and scrapes the results as a native function to the mush. this allows you to integrate anything externally as an internal function call. Very useful for integrated coding.
Pros:
- It allows you to execute any external binary/script/function/feature as a native MUSH function
- It allows you to push and pull data from this.
Cons:
- There is no real 'call back' feature to it
- You can not have execscript() call internal code interactively and must pass data to and from it
- You can't run processes in the background and scrape the data at the same time
EXECSCRIPT()
Function: execscript(<script name> [,<arg 0>,...,<arg 9>])
Note: This function issues a shell interpreter so will have some
overhead compared to calling it natively through an API.
Requirements: /usr/bin/timeout (on MacOSX link to /usr/local/bin/gtimeout)
script/binary existing in ~/game/scripts and chmod u+rx
@powered EXECSCRIPT GM or higher
Set SIDEFX (with the sideffect EXECSCRIPT enabled)
This function executes a script called <script name> in the game
directory
illegal characters (like, .., /, $, etc) from the script name.
This requires the EXECSCRIPT @power of GUILDMASTER to use the function.
It requires the ARCHITECT level to allow the use of passing arguments
to the script. Unlike other powers, this power is not inheritable.
You can pass a maximum of 9 arguments to the script not including the
script name.
The following variables are available from inside the scripts called:
MUSH_PLAYER - [%!] dbref# of player followed by name of player.
MUSH_CAUSE - [%#] dbref# of cause followed by name of cause.
MUSH_CALLER - [%@] dbref# of caller followed by name of caller.
MUSH_FLAGS - the flags of the player.
MUSH_TOGGLES - the togglesof the player.
MUSH_OWNER - dbref# of player
MUSH_OWNERFLAGS - the flags of the player
MUSH_OWNERTOGGLES - the toggles of the player
Examples:
> say execscript(hello.sh)
You say "hello from the script."
> say execscript(hello.sh,test)
You say "hello from the script with args: 'test'"
See
See Also: POWER EXECSCRIPT, exec_secure
- The lovely API interface.
This is a full grown http header based API call. It's similar to a RESTful API in how it works, but is header driven. You pass it arguments via headers to execute code and tell the MUSH how it's to parse the results.
Pros:
- A fully interactive and restful(like) API that is entirely header driven
- Allows you to push and pull data to and from the mush and execute mush code from within any external app
- Anything that talks normal HTTP 1.1 via liburl or normal url calls will be able to use the API
- Allows rapid connectivity to the mush and has no restrictions on what it can execute
Cons:
- No real callback feature, though you can work around it by having the API use execscript()
- If you queue data from an API you have to use a second API call to gather the results
- No persistent API connection
- No SSL layer (currently) is available
API
Topic: API
RhostMUSH has a process where it allows API connections to happen on another
port. It requires to have the api_port specified to a unique port for the
API handler, then various optional config parameters to optimize how the
API works. The API, unlike normal connections, allows any valid dbref# to
talk to the mush from the API engine. It does this through multi-factor
authentication including host match and password authentication.
Keep in mind, the API port is NOT the mush port. It is a different port.
There is also quite a lot of protection on the API port which will
automatically disable the object or the IP from connecting if abused.
It uses Basic Authorization and encapsulates. Example of using curl for
login authentication to the API's object would be:
curl --user "#123:foobar"
The dbref# would be #123, and the password you want to authenticate would
be 'foobar'.
Example curl commands that are used for the API handler are:
GET Examples (this is from a command line using the 'curl' application)
> curl -X GET --user "#12:ya" -H "Exec: [lnum(10)]" --head http:
POST Example: (this is from a command line using the 'curl' application)
> curl -X POST --user "#12:ya" -H "Exec: @emit hi!" --head http:
To have a target dbref# enabled for API processing, please alert a staff
on your game as it requires staff approval and authentication to enable
the dbref# to be useable for the API sub engine.
{ see 'help api return' for expected return codes }
Granted, this is not a perfect solution for coders, but I believe it empowers them to do a lot of things in MUSH that would normally be impossible to even consider and contemplate.
Hopefully as time passes RhostMUSH will continue to 'grow up' and continue to be a 'Big Boy' 