----- Original Message -----
From: Cecil Bayona <[cbayona--operamail--com]>
To: <[rebol-list--rebol--com]>
Sent: Monday, February 19, 2001 3:56 PM
Subject: [REBOL] Re: /View As A Product
> Get over it buddy, if you want to start & push your own product to compete
with Rebol, GET YOUR OWN MAILING LIST. There,
> I feel a lot better now.
Hey, stop this, please??? :-/ Your post is very offensive, sorry. There are
some valid points in Mark's message. At least RT folks have some food to
think about :-)
Cheers & peace,
-pekr-
> Cecil Bayona
>
> 2/19/01 3:38:53 AM, [Robbo1Mark--aol--com] wrote:
>
> >The more I read over Holger & Jeff's recent comments
> >regarding some of my post to this list, the more angry
> >and annoyed Iam becoming.
> >
> >Somehow Iam being painted as the BAD GUY here, as if
> >Iam highly unethical, unscrupulous and down right wrong!
> >
> >My opinions might be wrong for some people, I can accept that, but that
is surely what debate and constructive criticism is all about.
> >
> >I have never once criticised REBOL Technologies or any
> >person who works there. I may disagree with their strategic directions
for REBOL but I've never once said they are wrong or urged them to make
> REBOL open source.
> >
> >I fully respect their rights to pursue whatever strategy they feel is
best for them and their company.
> >
> >Iam not the ONLY person who would prefer that REBOL source code was
openly available and freely distributable, I wish this was the case but I
would
> never say REBOL Technologies Inc. should or shouldn't do this or that.
> >
> >I have never criticised REBOL products on their technical merits, I do
feel that /Command is not good value for money and that thesuggested pricing
> levels for /Express may be too much for some people and discourage rather
than encourage some people from
> >using REBOL, but that is a commercial decision for the peopleat REBOL, I
can only make my choice in the market place and decidewhether or not to
> buy these products. I have never and would never try to tell Carl or
anybody else how to run their business.
> >
> >However people on this list DO have some concerns and frustrationsregards
some of REBOL's capabilities or future product directions.
> >
> >let's look at three which have been discussed here recently.
> >
> >1. /Apache
> >
> >2. REBOL-CGI
> >
> >3. /Shell features in /Core
> >
> >/Apache was a product that was in development and was under BETAtesting
to selected developers. However it has recently been statedby REBOL
> Technologies Inc. that although /Apache remains as a "Strategic" future
product for REBOL it is not under active development just now. So people who
> would like to do server side
> >scripting with APACHE server and REBOL now have to wait indefinitely for
this to be developed or pay something like $2500 US Dollars for an /Express
> Server licensing fee.
> >
> >This decision is almost certainly financially oriented by REBOL
Technologies Inc. need to get revenues, which is perfectly fine, you are a
business entity
> after all.
> >
> >But what about the people who need or would like to do REBOL & Apache,YOU
are not addressing their needs, that is rightfully your decision.Is it
> unethical to suggest an alternative strategy, that rather than waiting for
REBOL to do something someday, that these people might
> >take matters into their own hands, and help themselves by considering an
open source REBOL which they can adapt to suit the needs of server side
> scripting and integration with APACHE webserver.
> >
> >Next up REBOL-CGI, various people have made comments to this list about
REBOL's effectiveness and speed in doing CGI. The speed issue is
> affected by REBOL loading and decompressing it's internal source for each
instance of CGI. I think it was [chris--starforge--co--uk] who recently
> commented that this is on the margins of what is acceptable performance
for CGI operations. This was in respect to not having a /Core product
> >and only having /View. Now this is probably unlikely, but in any event
REBOL still suffers in this respect in that /Core is a very good but still a
general
> purpose interpreter.
> >
> >Correct me if Iam wrong but I don't think REBOL is optimised in any way
for CGI.
> >
> >REBOL has a deficiency here in that a one-size-fits-all-needs interpreter
cannot be stripped down to suit the needs of CGI.
> >Python, Perl, Ruby & TCL etc. in particular have this advantage because
they are open source. A minimal interpreter can be produced specifically for
> CGI processing. This mapping of the solution to the
> >problem is not possible because REBOL is only available in binary
executable format.
> >
> >I can't remember anyone from REBOL ever saying that a CGI specific
interpreter is on the top of the priorities list, so again what do these
people do if
> they want to use REBOL for CGI but with improved
> >performance?
> >
> >Also REBOL/Core cannot be easily be used as an embedded interpreter in
applications although it is potentially ideal for this purpose.
> >TCL, Perl & Python all have capabilities to embed C programs in scripts
and also themslves be embedded within other C applications & programs.
> REBOL doesn't do this yet, and also will it be possible to do this in
REBOL for free?
> >
> >Which brings us to /Shell features being available in /Core.Petr
Krenzelok has argued the case for this for nearly two years as well as a
clear roadmap
