[REBOL] Re: The REBOL messaging engine
From: joel:neely:fedex at: 11-Aug-2003 16:07
[Possible dup, sorry if so, network glitch while sending]
Nice work! Here are a few $0.02 answers to your questions...
Maarten Koopmans wrote:
> 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, ...
Leave it to the message implementors. Do the simplest thing that
could possibly work. (It's always possible to complicate life at
a later date! ;-)
> - 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?
Make basic message interchange language neutral, for the following
- The trend of the industry is away from "lock-in" mechanisms (even
if the pace is erratic!)
- The most successful 'Net protocols are language neutral (HTTP, FTP,
- If (as I assume) at least part of the goal is to strengthen the case
for REBOL, I believe that it hurts the cause to send a message (pun
intended) to the world that says "Here's another closed environment.
Use our language so you can use our tools." Most developers won't
make that investment without some significant (short-term) payoff.
The best position for REBOL would be "Here's a transport that can
be used by any language. Here are benefits of using that transport.
OBTW, REBOL is demonstrably the best language for doing so."
- Chicken and egg (Most developers won't take time to learn a new
language/transport unless there's already something there. Most
developers won't build something there unless they believe there
will be something else later -- including users.)
> - Is this API with server based handler functions a good concept or
> is it too hard for most programmers?
Sounds elegant, clean, and easy.
> - 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?
For a first cut, how about just a list of all the words for which
handlers are bound?
> - 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.
Couldn't that be the responsibility of the handler?
> - 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.
Could there be a refinement to manage the error-handling strategy?
For instance (better naming is certainly possible!):
to attempt and return NONE on failure, but
to attempt and return error on failure (in which case one certainly
should wrap in a TRY block...)