----- Original Message -----
From: Cecil Bayona <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
> for componentization in REBOL. As far as I can see his words have fallen
of deaf ears.
> >What if you want /Command features with /View or /Shell availablein
/Core, this has never been clearly answered.
> >
> >/Command to me doesn't strike me as good value for money for it'sextra
feature set, but that is a personal opinion.
> >
> >The /Shell command 'CALL which passes a message string! to the operating
system shell seems to be not much more that a REBOL implementation of
> the ANSI C EXECL () function.
> >
> >Sure /Command has /Database, /Library & Encapsulation functionality as
well but if you only want /Shell then $250 dollars is a high price to pay.
> >
> >With an open source REBOL you could add this functionality yourself.
> >
> >And that is the whole crux of my posts. OSCAR: :REBOL is not vaporware, I
have never claimed it can do this or that. Right now it cannot do anything
> as we are only at the reverse engineering, design & specification phase.
> >
> >However OPEN SOURCE provides a mechanism for people to address these
areas of "missing" functionality in REBOL. If for whateverreason you
> choose not to provide or prioritise these "needs" people have then you
what is unscrupulous and untactful tosuggest people help COMPLEMENT the
> existing REBOL offerings by developing an open source REBOL in these
directions.
> >
> >OSCAR by definition can only ever have whatever functionality people are
willing to put the time and effort into producing.
> >However because it is open source, it can in theory be pushed in any
direction people want to take it.
> >
> >I realise the commercial pressures REBOL Technologies Inc. operate within
and you literally do not have the resources to DO & prioritise everything.
> >
> >You have chosen your strategic space and direction for REBOL.Is it really
so wrong for me to want to help these people provide complementary
> improvements to REBOL rather than simply asking them to have faith,
patience & please wait.
> >
> >These are real needs that real people have NOW!
> >
> >What is wrong with OSCAR trying to fill this space if you won't or can't?
> >
> >Iam only trying to improve REBOL as a technology, does this make me a bad
guy?
> >
> >Mark Dickson
> >
> >
> >--
> >To unsubscribe from this list, please send an email to
> >[EMAIL PROTECTED] with "unsubscribe" in the
> >subject, without the quotes.
> >
> >
>
>
>
> --
> To unsubscribe from this list, please send an email to
> [EMAIL PROTECTED] with "unsubscribe" in the
> subject, without the quotes.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
