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, [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.
