[REBOL] Re: The REBOL messaging engine
From: antonr:iinet:au at: 13-Aug-2003 14:46
Sounds great, Maarten!
> - 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, ...
Encryption is pretty necessary these days. It would be nice
to have it built in, though as noted, not necessary.
It's pretty easy to add, isn't it?
But, don't call the functions like rugby, by just changing
first letter (rexec -> sexec). I didn't think these were
nice function names, although they were nice and powerful ones.
> - 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?
Seems ok to me. I can't think how to make it simpler.
I think "add-message-type" is not a good name?
How about "add-message-handler". That's what you are doing
after all. (is that in use somewhere else?)
Maybe if you make the handler [any-function! block!], and if
user passes a block, add-message-type makes a new function using
the block as the body.
> - 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?
Yes.
At least return the help of the handler function.
(That is, just send back what rebol help returns for that function.)
I suppose the implementor is most likely to use built-in
rebol function documentation to show how to use that
dialect.
Help should be a built-in message handler.
For security, some message types should be able to hide their
presence on the server.
> - 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.
I think so. Otherwise anyone is running your code.
> - 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.
I think errors should be returned. You want to see what's wrong.
Clients, now, can always just use attempt if they want a none on error.
Doing it the other way is just confusing.