[REBOL] Re: Commercial-quality REBOL programmers needed
From: petr:krenzelok:trz:cz at: 16-Aug-2002 8:36
>>** Original Subject: [REBOL] Re: Commercial-quality REBOL programmers needed
>>** Original Sender: Petr Krenzelok <[petr--krenzelok--trz--cz]>
>>** Original Date: Thu, 15 Aug 2002 01:13:02 -0500
>>What is imo needed, is kind of a standard protocol framework, we could
>>build upon. We need more protocols and library wrappers etc. I hope it
>>will come. Stuff belonging to such library is:
>>- some of Andrew Martin's job
>>- new coming protocol framework
>>- fastcgi, mysql, postgress protocols
>>- Gavin's XML stuff
>>What is a bit problematic is, that all above mentioned stuff uses its
>>own logic, architecture, etc. So initially, all above mentioned stuff
>>could be considered being separate products. Let's hope some
>>ground/framework, upon which we all could build, will come ....
>I am new to the list. (Don't hold that against me)
>I would like a little clarification.
>1. Standard protocol framework:
> What does this mean?
Well, if you are new, try to look under the hood of Rebol. Download some
Rebol system viewer, %browse-system.r or gui version "ana-monitor.r?
Don't remember exactly ... Then you will see, that Rebol system
structure holds something like system/schemes path, where all rebol
protocols are stored.
What also rebol does - it provides abstraction mechanism called "port".
The principle is simple - you open the port, 'insert data into it, copy
data from port, close the port. We have plenty of ports - files,
network, sound, encryption, odbc, etc.
If we consider building new schemes (protocols), we should do so around
port mechanism. Some time ago Jeff Kreis described how to build custom
protocols - http://www.rebolforces.com/articles/protocols.html and
Holger posted nice follow-up (you would have to find it on escribe ...)
> Why is it needed?
because - RT provided some standard set of protocols. We of course need
more. But if every programmer builds it in his/her own logic, we will
end-up using X protocols in Y different ways and that is not the way to go.
What is more though - you have tcp family protocols, but is that
sufficient? You want to communicate, right? You want two machines talk
one to each other? Great, so you have to build kind of a client, and
server. But then you want probably your server to understand some
commands? OK, so you build protocol, for your server communication. But
- that protocol will be probably useless for anyone else. So, I can
imagine tool, which will serve as communication matrix, dispatcher, call
it whatever. It should allow to:
- bind protocols on certain ports
- define callbacks for certain kind of events happening on port .... eg.
on-length, on-char-received, etc.
- define handlers
- define amount of child processes to be started (we have no threading yet)
- be dynamic. I don't accept anything not being able to dynamically
bind, unbind stuff at runtime, without the restart.
- watch the status - monitor
So - if such framework would exist, if it would be good enough, most ppl
would concentrate upon it, and build stuff for it = central starting
base, unification, consistency. It should imo also become native part of
As I said, hopefully, it is coming .... :-)