Define serial protocol for Messaging. #195
Conversation
|
|
||
| ##BEGIN | ||
| Must be called after creating a Serial connection, it can take either just a host for accessing public variables or you may also provide a secret for accessing protected variables in the database. | ||
| ##BEGIN_DB |
There was a problem hiding this comment.
what do you think of doing BEGIN SERVICE ARGS?
There was a problem hiding this comment.
Hmm... I am not sure. I could see some advantages. It may make the service registration system easier. You can try to load a service called "SERVICE" when the command is actually called.
There was a problem hiding this comment.
Let's think about it some more. I am not going to block on it. We will need to change the database implementation to match so it could be a followup PR.
serial_protocol.md
Outdated
| >> MSG_USERS fQCLfBOGdh0...9k0 fQCLfBOGdh0...5j1 | ||
| << +OK | ||
|
|
||
| ## MSG_TOPIC |
There was a problem hiding this comment.
maybe specific which parameter is optional and if there is a default.
Added errors for BEGIN_MSG.
Addition doc changes
| time_to_live=500 | ||
|
|
||
| ##Usage | ||
| MSG %Argument% %Argument% ... |
There was a problem hiding this comment.
do you think a single line variant would be useful? (maybe we can distinguish with suffix like we did originally for db).
Something like:
MSG "TITLE" "INLINE_BODY" [data_key=data_value ...]
|
Let's merge and iterate! |
2 participants
No description provided.