newipc2 Branch

This branch abstracts the IPC functions out.

Status

  • Branched from jscript.
  • In development, not yet integrated into the trunk.

Maintainer

The branch owner is FireFury.

Documentation

I am contemplating a "break the world" release to try and reduce the amount of fscked in the head stuff in the MW IPC mechanism.

At the moment, a lot of stuff is just passed as raw text, such as "foo has changed room". The sending side decides what text should be sent, so the sending side has to do stuff like look to see if the receiver has mudmode on, etc. A far better idea is to define some new message types to send this data to the remote Milliways and let the recipient's client decide on the text to be displayed.

The sending side must also decide which users need to get sent a message. This complicates things and it seems it would be easier to move this functionality to the receiving side. The sender would send messages for a specific user to only that user and everything else to everyone. The receiver would then throw the message away if it didn't care about it. This would make multiple logins work better since the userDB record (which is incorrect for one client) wouldn't need to be consulted for most operations. Also, it would fit more inline with the client/server model.

Primitives

Each message contains a message type ID, the sender's PID and possibly some parameters. Current primitive messages are as follows:

IPC_NEWMAIL

Tells the remote process that there is new mail

No parameters

Sent by:

  • !write
  • !reply

IPC_STATUS

Tells the remote process to set its user's status flags

Parameters:

  • New status flags

Sent by:

  • !user status
  • !user edit (should happen, except it doesn't)

IPC_GROUPS

Tells the remote process to set its user's groups flags

Parameters:

  • New groups flags

Sent by:

  • !user groups

IPC_REALNAME

Tells the remote process to set its user's real name

Parameters:

  • New real name string

Sent by:

  • !user realname

IPC_CONTACT

Tells the remote process to set its user's contact address

Parameters:

  • New contact address string

Sent by:

  • !user contact

IPC_LASTREAD

Tells the remote process to set its user's lastread pointer for a specified folder

Parameters:

  • Folder index
  • Message number

Sent by:

  • !user lastread
  • !addfol
  • !autosub

IPC_SPECIAL

Tells the remote process to set its user's special flags

Parameters:

  • New special flags

Sent by:

  • !user special

IPC_TIMEOUT

Tells the remote process to set its user's timeout

Parameters:

  • New timeout in seconds

Sent by:

  • !user timeout

IPC_USERNAME

Tells the remote process to set its user's user name

Parameters:

  • New user name string

Sent by:

  • !user username

IPC_COMMAND

Tells the remote process to execute a command

Parameters:

  • Command string

Sent by:

  • !force

IPC_CHATPRIVS

Tells the remote process to set its user's chatprivs flags

Parameters:

  • New chatprivs flags

Sent by:

  • !user chatprivs

IPC_CHATMODE

Tells the remote process to set its user's chatmode flags

Parameters:

  • New chatmode flags

Sent by:

  • !user chatmode
  • .protect
  • .unprotect
  • .freeze
  • .unfreeze

IPC_KICK

Tells the remote process to remove the user from the talker

Parameters:

  • Type of kick action (ZOD, MROD kick, remove)
  • Optional reason string

Sent by:

  • .zod
  • .mrod
  • .kick
  • .remove

IPC_PASSWD

Tells the remote process to set its user's password

Parameters:

  • New crypted password string

Sent by:

  • !user passwd

IPC_CHANNEL

Tells the remote process to set its user's talker room

Parameters:

  • New talker room number

Sent by:

  • !user room
  • .summon

IPC_GAG

Tells the remote process to set its user's talker gag

Parameters:

  • *** no idea - how does this work? ***

Sent by:

  • .gag
  • .ungag

IPC_CLEARIGN

Tells the remote process to clear its user's ignore list

No parameters

Sent by:

  • !user clearignore

IPC_PROTLEVEL

Tells the remote process to set its user's protection level

Parameters:

  • New protection level

Sent by:

  • !user protection
  • .protect
  • .unprotect

IPC_PROTPOWER

Tells the remote process to set its user's protection power

Parameters:

  • New protection power

Sent by:

  • !user protection

IPC_WIZ

Message to super users and people with the Wiz priv

Parameters:

  • Raw text to display

Sent by:

  • !board
  • !wall
  • postinfo()
  • send_mesg()
  • accept_line()
  • close_down()
  • time_out()
  • !wiz
  • !emote
  • Change Info messages

IPC_TEXT

Talker message

Parameters:

  • Raw text to display

Sent by:

  • Say
  • .shout
  • .raw
  • .>
  • .>>
  • .room
  • .sayto
  • .notsayto
  • .whisper
  • .emote
  • .emote's
  • .emote'
  • .quit
  • .protect
  • .unprotect
  • .summon
  • .freeze
  • .unfreeze
  • .gag
  • .ungag
  • .ignore
  • .unignore
  • Sender enters talker
  • Sender received IPC_CHANNEL
  • Sender received IPC_KICK

FORCE_TESTING

*** REMOVED *** Tells the remote process to .ignore the sender

No parameters

Sent by:

  • Sender logged on (with special I flag)

IPC_CHECKONOFF

Tells the remote process that the sender has entered of left the board or talker

Parameters:

  • Type of event (joined talker, left talker, left board, entered board)
  • Why the event happened (normal, summoned/timedout, CM_ONCHAT was removed/too many EOFs, quit Milliways completely straight from the talker (!quit)/MROD, banned, error)
  • Quiet logons flag
  • Name of user that caused the quit (e.g. sender's name if !quit was used, or the name of the user who sent an MROD, etc.)
  • Optional reason string

Sent by:

  • Sender received IPC_CHATMODE causing CM_ONCHAT to be changed
  • Sender received IPC_CHANNEL
  • Sender received IPC_KICK
  • Sender logged on
  • Sender logged off
  • Sender left the talker
  • Sender joined the talker

IPC_SCRIPTIPC

A script-to-script IPC event

Parameters:

  • A text string

Sent by:

  • Scripted SENDIPC

IPC_SCRIPTRPC

A script-to-script RPC event

Paremeters:

  • RPC type string
  • A text string

Sent by:

  • Scripted SENDRPC

Proposed New Primitives

IPC_JOINTALKER

Broadcast by a client when it enters the talker. There are no implicit room subscriptions - the client needs to send IPC_ENTERROOM to join new rooms. Room subscriptions MAY persist between sessions.

No parameters.

IPC_LEAVETALKER

Broadcast by a client when it leaves the talker.

No parameters.

IPC_ENTERROOM

Broadcast by a client when it enters (subscribes to) a talker room. Currently a client can only be subscribed to a single room at once, so IPC_LEAVEROOM must be sent before IPC_ENTERROOM. This is expected to change in the future.

Parameters:

  • Room number

Notes:

  • Maybe this event could be used to toggle global on/off too?

IPC_LEAVEROOM

Broadcast by a client when it leaves (unsubscribes from) a talker room.

Parameters:

  • Room number

XML Ideas

Normal talker messages could be sent using XML similar to: 

<chat>
        <origin id="12345">FireFury</source>
        <destination type="room">foo</destination>
        <destination type="room">bar</destination>
        <destination-exclude type="user">baz</destination-exclude>
        <message-type>emote</message-type>
        <message content-type="text/plain">quux</message>
</chat>

This would easilly support messages from Say, .emote, .raw, .sayto, .notsayto, .shout

Event messages 

<event type="logout">
 <origin id="0">System</origin>
 <destination type="all" />
 <victim id="123456">FireFury</victim>
 <reason>timeout</reason>
 <message content-type="text/plain">Wowbagger the infinitely prolonged has just evicted FireFury</message>
</event>

To prevent Breaking the World we should also include the old format pre-rendered string inside every message, in an encoded format because its binary. A client should try to send the mixed format message to the server first, if hasnt got a session to the server then fall back on the old fifo mechanism, To work fully every client would have to switch to this method from the beginning, but once switched it would not matter if the server broke, nor matter how far along the migration a client was, they would all still interoperate.

such that immediately after the client-server switch every client would be sending messages containing just the encoded old message. and only understanding that part of any incoming message. As the features are migrated (by adding the new message format as well as the old one) then clients will start to understand more and more, but older clients can still fall back. once the migration is complete you make sure all clients are switched and remove all the old format stuff.

this method assumes that for the moment we stick to the client understand what all the commands are, and simply asking the server to distribute a message to a person or room as per the above xml examples.