[REBOL] The REBOL messaging engine
From: maarten:vrijheid at: 11-Aug-2003 20:25
Hi All,
I have been working on a messaging engine lately. It always seemed
strange to me that REBOL was designed for semantic exchange but didn't
have a send-message function on board.
I have some cool stuff working, but I have some questions to my
potential user-base ;-) I expect to have a beta out in a few weeks.
Right now there is a server and a client part.
To support a message type on the server-side you call one function:
Add-message-type: func [ 'w [word!] handler [any-function!]][...]
So you'd get: add-message-type echo func [ b [block!]][b]
which would be an echo handler. Note that the handler function must
expect a block (containing.... a message = dialect).
The server engine is completely based on async I/O.
The client side is one function as well:
Send-message: func [ 'w [word!] u [url!] msg [block!] /deliver f
[any-function!]][...]
So you'd get:
Send-message echo tcp://localhost:8000 [{Echo this}]
This will wait for the answer and then return.
Optionally you can do it asynchronously when your in an event loop (e.g.
View):
Send-message/deliver echo tcp://localhost:8000 [{Echo this}] :print
This will continue execution immediately and when the result is
completely back it will be delivered to the print function, much like
events in View. Asynchronously!
The idea is that you can easily implement simple protocols as different
message types, with each type having its own dialect. For example, a P2P
set of messages would be 'publish 'locate 'delete 'get with their
handler functions. Or you could have a Rugby handler, or....
Now some questions:
- Should I add (optionally) message encryption or leave that to
implementors of messages, as their needs may vary? Pro: Ecnryption Con:
only works with the SDK, Command, ...
- Should I work a bit on the message format so we can port it to other
languages as well (.NET, Python, etc.) or keep it REBOL-only and enhance
it, for example integrating a new Rugby on top of this?
- Is this API with server based handler functions a good concept or is
it too hard for most programmers?
- Should I add meta-data so you can query an engine to see what messages
it udnerstands. If so, what should the meta-data look like?
- Should I add authentication, so you can demand that a message must be
properly authenticated? If so, I'll probably keep it pluggable, meaning
that you can add your own authentication methods as well.
- Should I transparently propagate errors back from server to client or
just return none when an error occurs? It may be annoying to do a try
with each send-message, OTOH seeing what goes wrong is worth something
as well.
- Any other suggestions?
--Maarten