[REBOL] Re: Commercial-quality REBOL programmers needed
From: petr:krenzelok:trz:cz at: 15-Aug-2002 7:40
Hello Bo! :-)
first - it's nice to see old time reboller to prosper using Rebol :-)
Rebol and business, well, well, well. There is several povs to the problem:
1) historically - RT did a BIG mistake locking library and shell
components, period! I am not even open to discuss it further, as I can't
see any pov which could change my opinion here. All the situation
resulted into strange Rebol position on market - we lost MANY newcomers,
because they were not able to freely link to external resources.
Let me clarify first - I am not for Rebol becoming open source. However,
for me - the main goal is - interoperability. Systems talking one to
each other - middleware. What Rebol became however, was closed
environment. That's probably the reason we still can't see Rebol
mentioned with many open libraries, as there is not enough manpower in
our community, to create such wrappers. Not so many ppl own /Pro version
imo.
2) /Command low priority. I think that Rebol could become top quality
middleware product. The money lays in corporate sphera - big money. I
work for company, where the main system is SAP and supporting products.
Look at WebMethods Business Integrator - 50K per CPU. While I think IOS
is fine, RT would be better in that league imo.
But what do we have for /Command today?
- native mySQL protocol, which according to some reports, is even slower
than DocKimble rebol-level one
- ODBC, Oracle - fine (tested only odbc though)
- fast-cgi, which does not adhere to the latest development in that
regard (RT's own implementation)
- /Pro stuff - library, shell, security stuff (limitations - look at the
bottom of following site though - http://www.rebol.com/docs/ssl.html)
now what do we lack? Rebol has nice abstraction mechanism - ports. Life
of Rebol developer would be easier, if at least some of following
components/ports would exist:
- COM/DCOM - linkage to that MS technology would open much wider field
for Rebol to be used.
- other DB protocols
- JDBC?
- and the most critical one - proper XML support. If you will look at
latest development in many product areas, everything is going XML route.
And excuse me - I don't want to hear the opinion, that parse this or
that is easy and that I should implement it myself. Wrong! If some
product uses SOAP 1.1, RosettaNet X.y, ebXML X.y, I just want to 'load
module, and use it for the task needed, that's all.
IF we don't get those protocols, we are doomed, because noone will
seriously consider Rebol as a real business player. If e.g. SAP is able
to offer programmer automatic conversion of module interfaces to SOAP,
programmer even does not need to care of SOAP internals. I can hardly
push those ppl to use different format, while OTOH I don't have free
resources to care of parsers etc. stuff - I need to USE the solution,
not to implement it.
I think that RT could contract such work, and maybe there would be
enough ppl even today, which would buy such updated /Command version,
even for some + 1000 USD. RT choosed slightly different path, and we
have to respect it - after all - IOS is good product, nothing against
it, but then - if /Command is not updated soon, it deserves to be
removed from product family, because it is old, and starting to be
underpowered ....
what is more, we will probably sooner than later see mySQL + PostGress
released by old time good rebol fellow. What is even more, I hope even
free fast-cgi is gonna be released too. Don't make me wrong, but what is
all that new 'build-markup good for, if used in CGI mode? So, after the
release, except the ODBC and Oracle, /Command has no reason to exist
anymore, as /Pro will be sufficient.
If you think I am too much negative - think just opposite! I will form
my own company in a half a year (registration pending :-). I think that
for the scripter, ability to link to other systems is crucial. That's
why I tried to suggest creation of some kind of rebol developers
library. Maarten started some way, but Rugby is a bit alone. Kind of a CPAN?
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
- Rugby
- 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 ....
3) try to push rebol! :-) Bo, don't automatically agree to use different
technologies, because some client may seem to require them. Eh, you use
Perl? It fades, ppl are switching to Rebol, you never heard of Rebol?
What is it? The next big thing, etc ... just try it. I think that most
ISPs will allow you to run at least CGI in Rebol. The different thing is
with fast-cgi. And .... at the end, haven't you thought about setting
your own server?
So, let's see, what near future will bring to us :-)
Cheers,
-pekr-
