-
Notifications
You must be signed in to change notification settings - Fork 1
URSYS messaging future upgrades
I spent a few hours trying to add CHANNEL support to our messaging scheme. The idea of channels is that when creating a subscribing message function or calling a message, we can specify whether it is LOCAL, NET, or BOTH. Simple enough, but the underlying infrastructure is actually quite attuned to NOT using channels. It instead uses three options that are added through URLINK to the underlying MESSAGER class:
-
toNet
is set true byNetCall, NetSubscribe, and NetPublish
-
toLocal
is set true byLocalCall, NetSubscribe, and NetPublish
-
fromNet
is set only bym_HandleMessage()
when receiving a packet from the network, which tells MESSAGER that it should call the local message handler defined for it appropriately.
I found it confusing to keep directions straight. The Net* and Local* calls are written from the client authoring perspective, and the three options are also named from that perspective. The tricky part is tagging the handler functions with channel information and inferring fromNet
.
A big question is whether the channel is defined as part of the message, but this creates the case where you might do a NetSubscribe('NET:MESSAGE') and then the incoming message from a remote needs to invoke the message LOCALLY instead of reforwarding it to the net. The logic is a little convoluted and the testing code I have is too unreliable to help debug this cleanly, so I've punted on it until I get a chance to rewrite URSYS as a standalone test-driven-design library.
User Manual
Developer Manual
Installation
Setting Up End-User Projects
Deploying
- Deploy Electron
- Electron Code Signing README-signing.md
- Digital Ocean Deployment
- Updating MEME for 2021+
--
Coding Practices
Background
Design Notes
- Dev Insights
- Design Data Management
- Student Login
- Reference Build Differences
- Design Settings Manager
- Why Electron?
Deprecated