Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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.