Cecil,
That was a bit uncalled for wasn't it.
Fact is that OSCAR (to which I have no affiliation, aside from wanting to
see it succeed), *does* have it's own mailing list.
Another fact is that this is simply a case of 'imitation being the sincerest
form of flattery'. REBOL rocks but the OSCAR people think an open-source
version would better serve the cause, simple equation.
See, it is possible to stay calm even when someone upsets you. Next time
you may want to think about that.
Phil
[phil--harris--zope--co--uk]
----- Original Message -----
From: "Cecil Bayona" <[cbayona--operamail--com]>
To: <[rebol-list--rebol--com]>
Sent: Monday, February 19, 2001 2: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.
>
> 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
