/View as a Product
[1/33] from: ptretter:norcom2000 at: 16-Feb-2001 7:49
Actually, I thought about this in great length. I think /View should be the
actual CORE product of which everything else is built on including /Command.
Additionally, I think /View should be offered for free as well. There is
plenty of room for RT to make products based on /View alone. If /View were
free then:
Most likely more people would use /View.
RT would not have to maintain a separation of /Core and /View.
I believe the Runtime approach is the best approach but expand it to include
/View that way RT makes profits off of /View scripts that customers want to
distribute. After all /View is the product that most users will want to
distribute their scripts in the Runtime format.
If this is all done as stated what need do we have for projects like Oscar
or other REBOL clones - wouldnt this be a deterrent to competition.
With this approach - those that have the time to learn REBOL are not
punished with purchasing the product after they have contributed time and
effort into learning the language and contributing where they can to this
list and to helping test the products. Obviously I would include within the
licensing of the product that any commercial use would be subject to a cost
to the user.
Just my two cents.
Paul Tretter
[2/33] from: chris:starforge:demon at: 16-Feb-2001 14:29
Paul Tretter wrote:
> /View that way RT makes profits off of /View scripts that customers want to
> distribute. After all /View is the product that most users will want to
> distribute their scripts in the Runtime format.
And what of those who just use Rebol for ci-scripting and the like? It
is important to keep the overhead of the interpreter for such scripts
to a minimum or the delay while loading, decompressing and starting
the interpreter will affect response times. /core is, I'd guess,
on the very edge of what is really viable as a run-on-demand cgi
interpreter for real systems. Perl is bigger in binary terms but
I don't think that has a compressed core. Using /view for cgi scripts is
a pointless waste of resources and time IMO.
Chris
--
New sig in the works
Explorer2260 Designer and Coder
http://www.starforge.co.uk
[3/33] from: robbo1mark:aol at: 16-Feb-2001 10:02
Paul,
Until REBOL is open sourced, if indeed it ever is then there will always be a place for
OSCAR or any other REBOL implementation.
REBOL is currently proprietary closed source technology, you have no means to adapt it
or improve to suit your own means. You cannot freely distribute it or copy it, nor learn
from it's implentation, well not directly anyway.
At the OSCAR project we are having to reverse engineer everything from scratch, whilst
initially this is "re-inventing the wheel", in the long term OSCAR will offer economic
efficiency and code re-use to developers by being open source free software.
You will be able to mold it to suit your needs, you don't want /View you can take this
functionality out. You want /Command features you can add them in. You require database
/ audio / video / device or whatever other interface imaginable, then you can adapt /extend
the program to cope with this.
REBOL internals will be laid bare for all to see and learn from, bugs / features will
be able to be fixed or improved upon at "YOUR" timescale - not somebody elses.
YOU will be empowered by OSCAR.
There is plenty of commercial scope for REBOL Technologies Inc. to make money from enterprise
solutions & packages.
OSCAR will be free software, no runtime licenses, no restrictions, this is the promise
of Open Source Code Also known as REBOL.
With your help we can make this a reality.
Besides competitiion is healthy, is REBOL in it's current incarnation really the last
word in the implementation of the language.
IS THIS REALLY THE BEST THAT REBOL CAN BE?
Why not OSCAR, J-REBOL ( that's SUN MICROSYSTEMS fictitious future JAVA - REBOL hybrid
) or any other Implementation ?
My two cents worth,
Mark Dickson
[4/33] from: holger:rebol at: 16-Feb-2001 10:24
On Fri, Feb 16, 2001 at 10:02:41AM -0500, [Robbo1Mark--aol--com] wrote:
> You will be able to mold it to suit your needs, you don't want /View you can take this
functionality out. You want /Command features you can add them in. You require database
/ audio / video / device or whatever other interface imaginable, then you can adapt /extend
the program to cope with this.
Yes, and it will do your dishes, laundry and taxes, too, I am sure.
> Besides competitiion is healthy, is REBOL in it's current incarnation really the last
word in the implementation of the language.
No, of course not, which is why it is being continuously improved.
> Why not OSCAR, J-REBOL ( that's SUN MICROSYSTEMS fictitious future JAVA - REBOL hybrid
) or any other Implementation ?
fictitious
is the key word describing your whole mail.
> My two cents worth,
Precisely that.
Personally, I am getting more and more annoyed by this. If you want to write an alternative
REBOL implementation then just go ahead and do it. Nobody from RT is holding you back,
and
I am looking forward to seeing actual results. However promising vaporware which is supposedly
going to be so much better than everything else, with the sole purpose of recruiting
developers for an open-source project in its infancy, and away from existing WORKING
and
AVAILABLE products, is, IMHO, a highly unethical practice, in particular if you do it
on
a competitor's mailing list. If you do it anyway then you may at least want to be honest
and tell users that it will likely take several years for OSCAR to reach the level of
functionality and stability that REBOL/Core has right now.
A certain company in Redmont, WA likes to make exactly those "our next release will be
so much better" kinds of claims whenever the competition announces a new product, and
those claims often have no or intentionally inaccurate information on product
availability. Just something to think about...
--
Holger Kruse
[holger--rebol--com]
Opinions expressed above are my own and do not necessarily
reflect the official position of REBOL Technologies.
[5/33] from: ptretter:norcom2000 at: 16-Feb-2001 13:25
I agree with Holger. I want to be successful financially as a REBOL
programmer some day when I master whats at hand now. As for some of the
comments regarding cgi why not have a command-line option for cgi that
basically unsets everything /view-like but still allows for cgi or what is
called /Core functionallity today. As for some Oscar project, like Holger
I'm curious how it will evolve but seriously think it will be a long
endeveour to bring anything close to what we have today and in fact believe
that the improvements that commercial involvement brings to the language
will far outpace anything open source even in years to come. There are some
values from a business perspective in having /View as the core. Maybe
take this approach that - simple common sense should be simple. :) I
believe someday that will be the case.
Paul Tretter
----- Original Message -----
From: "Holger Kruse" <[holger--rebol--com]>
To: <[rebol-list--rebol--com]>
Sent: Friday, February 16, 2001 12:24 PM
Subject: [REBOL] Re: /View as a Product
> On Fri, Feb 16, 2001 at 10:02:41AM -0500, [Robbo1Mark--aol--com] wrote:
>
> > You will be able to mold it to suit your needs, you don't want /View you
can take this functionality out. You want /Command features you can add them
in. You require database / audio / video / device or whatever other
interface imaginable, then you can adapt /extend the program to cope with
this.
[6/33] from: carl:cybercraft at: 17-Feb-2001 10:27
On 17-Feb-01, Paul Tretter wrote:
> Actually, I thought about this in great length. I think /View should
> be the actual CORE product of which everything else is built on
> including /Command./
As I understand it, Core is extracted from View, or at least used to
be. (The developement of Express might have affected this - I
wouldn't know.) Carl Sassenrath suggested once that View should be
the base product, (ie. no core), but protests here were quite loud
and it didn't happen. (:
/> Additionally, I think /View should be offered for free as well.
It'd be nice to know either way what it's commercial status is to be.
Trying to find any real information about View via the REBOL
website's frontpage now seems to be impossible. I just found the old
docs, but I had to use a search engine to do it.
I agree that View needs to be free if it's to become popular. (In the
way that Flash is popular.) To reach Flash's level of popularity
though, drawing, sound and (hopefully) 3D support will also be
needed. It's hard to be a View evangelist when it has no drawing or
sound support, or when your "Have a look at this script!" emails just
receive the "My View's expired again." response.
I'm hopeful though that after Express leaves beta RT will "finish"
View and it'll be released under the same conditions as Core. It'd
just be nice to know for sure that that is what RT is planning.
--
Carl Read
[carl--cybercraft--co--nz]
[7/33] from: agem::crosswinds::net at: 16-Feb-2001 22:51
Youch. Hard words, Jeff. But right.
But, rebol not open source? I'm surprised. For me it is.
In the same way as a pc+bios+linux is open source,
or the amiga+fish-disks (better).
(yep, hm, now there is an open-source bios, says /. , but i thought
this some hours ago :)
again, like amiga, Carl does a everywhere-the-same basis on which
hobby-inventors (writers of c-compilers, conman, arexx, muchmore)
can build.
Its a basis which has to teach a lot, which is important to influence
its
programmers.
This time Carl does'nt build the hardware.
hardware is the usual cause to get money (obviously you can't
disk-copy your box)
this time he simulates the hardware, which is equally hard
(decides the features which he can implement everywhere, but keeps it
being featueres, wow).
Since this is a hard part, i don't like my own extension in it,
finding i have to patch on every system around because the wonderfull
feature
i added on 'a is hard to implement on 'b .
it's a surprise for myself i accept this :)
so i think, Carl builds the machine, and i add on top of it.
I can add down to the »instruction set«, everythink possible is
meazine,
»open source«.
Yes, i know, i don't run /command on my similar expensive machine,
but this kind of pricing i invest every few years..
maybe next time for a virtual instead of a real machine, if
rebol keeps this performace :)
BTW a central person giving direction and basic code is very common
in open source, like Linus, all this language - inventors, ..
how many core-implementations of perl do you know?
Often this projects are funded by sponsors instead of customers.
It's another way. Like thinking TV with advertising is free.
A kind of university-structure for programmers
would be a better way, but else?
(poorer payment, but good equipment, nearby competent persons to talk)
BTW2 Mark, do you really think rebol needs three extra stacks? :)
Volker
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 16.02.01, 19:24:41, schrieb Holger Kruse <[holger--rebol--com]> zum Thema
[REBOL] Re: /View as a Product:
> On Fri, Feb 16, 2001 at 10:02:41AM -0500, [Robbo1Mark--aol--com] wrote:
> > You will be able to mold it to suit your needs, you don't want /View
you can take this functionality out. You want /Command features you
can
add them in. You require database / audio / video / device or whatever
other interface imaginable, then you can adapt /extend the program to
cope
with this.
[8/33] from: chris:starforge at: 16-Feb-2001 21:26
#16-Feb-01# Message from *Paul Tretter*:
Hi Paul,
> I agree with Holger. I want to be successful financially as a REBOL
> programmer some day when I master whats at hand now. As for some of the
> comments regarding cgi why not have a command-line option for cgi that
> basically unsets everything /view-like but still allows for cgi or what is
> called /Core functionallity today.
It still requires the all code to be loaded into memory, unless REBOL
is fragmented into various libraries (which raises serious cross-platform
issues). Even assuming load overhead is trivial - which it most certainly
isn't - the code then needs to be decompressed. Again, if the whole of the
package is in a single binary this either requires complex internal
compartmentalisation of the compressed code to optimise the decompression
or the whole thing, including the view code which is not required, has to
be decompressed.
Not insurmountable problems, but I can't see why it is necessary. I don't
know how the /view and /core source trees are related but I'd guess that
making seperate /view and /core distributions is not a particularly
troublesome task (I can think of several ways it could be done just with
preprocessor directives)..
Chris
--
New sig in the works
Explorer 2260, Designer and Coder
http://www.starforge.co.uk
--
Cold, adj.:
When the local flashers are handing out written descriptions.
[9/33] from: robbo1mark:aol at: 17-Feb-2001 5:55
Holger,
Iam honestly sorry as I seem to have offended you somewhat.
A couple of points I'd like to clear up.
1. I Love REBOL & wholehearted support REBOL Technologies. I honestly want
you guys to succeed both commercially and REBOL itself as a language,
otherwise I would be pretty stupid to want to learn more about REBOL, enough
to spend a lot of my time thinking deeply about it's internal workings, and
create an open free alternative. Why would I do this if I didn't want REBOL
to succeed?
2. Yes OSCAR just now is very much in it's infancy and at the current rate
will take a long time to match the current features of the existing REBOL
toolset, however if there is a consensus that an open source REBOL is a
worthwhile thing then people will want to contribute this & make it a
reality, this is how Linux & Perl & Python came into existence and continue
to flourish.
3. I do not see OSCAR or that groups mailing list as COMPETITORS of REBOL
Technologies Inc. or of this list. OSCAR is and will be about choice,
personal freedom & empowerment. I would like to think and I hope others would
agree that it is COMPLEMENTARY to what REBOL currently offers. Part of the
REBOL family if you like.
4. My reason for intially founding the OSCAR project was and remains twofold.
Firstly I see it as a massive but worthwile learning experience & opportunity
for both myself and the others on the group. I personally have learned so
much already that I consider the whole excercise to be very worthwhile.
Secondly If you remember the Slashdot articles about REBOL, we got absolutely
panned by that crowd, they beat us over the head with the open source stick
and "SOME" made valid points regards REBOL versus PERL, PYTHON & RUBY etc.
As someone who happens have respect for a lot of the principles & benefits of
open source free software, this personally hurt me, I love REBOL. It is my
language of choice. I want REBOL to succeed massively however to get certain
sections of the software community to even consider it you have to be open
source, hence to help REBOL make headway in these areas Open Source Code Also
known as REBOL.
I want these people who panned REBOL out of hand solely on the fact that it's
closed source to be forced to re-evaluate their opinion of REBOL.
Holger, I want to be your friend and would like to think we are fighting on
the same side, let us prove to the outside world that REBOL is "A Better
means of Expression" and help REBOL "the language" to succeed on ALL FRONTS!
It's all about choice, Just now we have only one choice REBOL versus the REST.
We have more to worry about in Java, MS Dot Net, Python, Perl etc. Let us
take on those people, not each other.
OSCAR is a friend of REBOL.
cheers,
Mark Dickson
[10/33] from: petr:krenzelok:trz:cz at: 17-Feb-2001 2:12
----- Original Message -----
From: Paul Tretter <[ptretter--norcom2000--com]>
To: <[rebol-list--rebol--com]>
Sent: Friday, February 16, 2001 8:25 PM
Subject: [REBOL] Re: /View as a Product
> I agree with Holger. I want to be successful financially as a REBOL
> programmer some day when I master whats at hand now. As for some of the
<<quoted lines omitted: 3>>
> I'm curious how it will evolve but seriously think it will be a long
> endeveour to bring anything close to what we have today and in fact
believe
> that the improvements that commercial involvement brings to the language
> will far outpace anything open source even in years to come. There are
some
> values from a business perspective in having /View as the core. Maybe
> take this approach that - simple common sense should be simple. :) I
> believe someday that will be the case.
What's the case with component system then? ;-) Don't forget ppl reported
View-as-CGI higher starting time than using /Core. But of course we can't
know how rebol works internally and if there is even some kind of boundary
(interface) between the Core and View itself, to be separated in the future
(View becoming just proper loadable/unloadable component). On the other
hand, IIRC, View is not loaded at the start time, untill some gfx stuff is
not called? Who knows why loading times differ.
And of course - Core = kernel. You can base /Apache upon Core, and View is
sitting there completly useless. Also don't forget than having things
separate, you can change one thing, while have another one untouched (e.g.
updates to View component could be done without the need for /Core change -
you just download new View component, that's the traditional library model
we know from many systems out there). But that's probably not important
nowadays (even if I can see it as more clear and natural way for Rebol), as
RT has to get their products to the market.
Noone would imo join OSCAR, if /Shell or even /Library would be available in
/Core for free. Isn't it pretty common functionality available in other
scripting languages? RT should not wonder then, that ppl get nervous about
it. There were countless requests for /shell like capabilities in Core ...
There is still plenty of room for RT to make money - especially in product
development. Freeing /Shell or maybe even /Library would help the situation,
but that's of course just my opinion.
Being part of Express testing (although I don't help as much as I would like
to), and discussing various stuff with RT staff, I have to tell you that
they are very open-minded ppl. Current state of things can change in the
future, and it imho will happen someday ...
Cheers,
-pekr-
[11/33] from: gjones05:mail:orion at: 17-Feb-2001 9:40
There have been many interesting comments made in this thread. I've had
a lot of food for thought, and over the last day or so I find myself,
like a cow, regurgitating my cud and chewing on it again.
I've been convinced for years that communication is a very fragile
process. It is very easy to inadvertantly step on each other's toes
(much in the same way that is is very easy for the neophyte to overwrite
array space in C, or to inadvertantly reassign "system" words in Rebol,
and I've had my share of both). I suspect that most of us agree on two
points: 1) REBOL is a very exciting language that still has some room to
grow, and 2) Holy Wars don't tend to be very productive. I don't see
that any Holy War has been started. All I see is enthusiasm that is
pushing to make REBOL succeed.
I spent the 80's and the first half of the 90's in the MS-DOS/Windows
world as a computer enthusiast (and not necessarily a Microsoft
enthusiast). I cummulatively spent thousands of dollars buying
exciting
solutions, and then spent innumerable hours learning to
utilize those "solutions". As with all things in life, I had varying
levels of success, with limitations being more dependent on my available
time or abilities. The one thing that held constant in retrospect, is
that change in the industry required a continuous investment of time and
money (both of which become tough to justify at the advanced hobbyist
stage). I came to really resent the money part, for whatever reason
(maybe I'm practical or maybe I'm just stingy). From my perspective, it
wasn't so much that I ever minded an initial financial investment, it
was that the speed of change requiring frequent re-investments, and
usually at higher and higher amounts (unlike most of the rest of the
software industry, or, for that matter, the tech industry in general).
I could readily see and appreciate that the developers needed to pay
bills, but I felt that there was an increasingly diminishing return for
my additional investments of time and money. As a favor to myself, I
stopped buying prepackaged software development tools, and resigned
myself to the fact that my "advanced hobbyist" days were probably over.
In the latter 90's, easy access to the Internet made it easy to see that
there was a whole world beyond MS-DOS/Windows. I was thoroughly
intrigued to find that there were very powerful solutions available
beyond BASIC/Visual BASIC, TurboPASCAL/Delphi, and C/C++/Visual C++, and
I was amazed that they were "free." The investment of time remained to
ramp-up to even modest levels of productivity, and I seemed to be unable
to grasp a productive use of Tk (and its various incarnations. I
figured that I had become "intellectually spoiled" by the GUI IDE's of
days past.).
I stumbled across REBOL a couple of years ago when I was doing a brief
survey of languages with references on Yahoo. I was intrigued by the
simplicity of doing the simple things (the website did a great job of
highlighting these simplicities). I didn't have much time to spare, and
when I worked on my first real program, I quickly could see that the
paradigm shift for solving more complex would require more investment in
time than I had. I left it alone, but kept tabs on it every few months.
There's nothing like being laid off to free up time, so I have recently
revisited REBOL, now fresh with the /View beta. Perhaps the Tcl
paradigm eased my transition into REBOL, but, as I have said elsewhere,
I've been amazed at how quickly I have become productive in both the
utility aspect of the language and the GUI. For the first time in
years, I felt a gush of enthusiasm. But the sting of my past lessons in
has begun to temper my enthusiasm. Some of the discussions of late have
underscored my need to maintain perspective. The recent demise of
Scriptics has punctuated the need to maintain some objectivity.
(As a brief side bar, Scriptics was begun by Ousterhout, the founder of
Tcl. His goal was to foster the continued development of Tcl in open
source mode, while paying the bills by selling a more sophisticated
debugger and program wrapper, and by developing and promoting enterprise
level middleware to address the new era of commerce on the Internet. Of
course, this is a familiar theme that is not unique to Tcl/Scriptics nor
REBOL/RT. Recently practically the whole staff, including the founder,
was basically bought out to move their daytime energies to a different
environment. While it was pointedly denied that they were not able to
move their paying product to the point of sustainability, that they
merely decided to devote their energies elsewhere, I can't help but
wonder if they weren't seeing the writing on the wall given their
situation and capitalization.)
At this juncture, let me state clearly that I am **not** implying that I
think RT is headed down the same road.
After this lengthy introduction, I'll finally get to the reason I am
writing. People who program for a living will always need to invest
significant time and possibly money into the skills and tools necessary
to succeed. I personally believe that what we consider to be intuitive
is probably subconsciously learned. If a language matches the intuitive
sense of the person, then the language will be more acceptable to learn
provided the the person is initially exposed to its existence. (By way
of example, I offer that a highly engineered language like Eiffel that
is linguistically restricted will seem very "intuitively" different to a
person who finds Ada to be intuitive than a person who finds Lisp to be
intuitive, and yet no one would likely doubt that Ada and Lisp were
successful in their own relms.) Although the number of "professional"
programmers is growing, so to does the landscape of available languages
and paradigms. I don't *know* this to be true, but I suspect that the
percentage of market growth of REBOL amongst professional programmers
may always be limited unless there is either a clear and compelling
advantage that is brought to the attention of the audience and/or there
is a virtual monopolistically-limited growth of alternatives (I suspect
that the growth of Visual BASIC, for example, benefited from both).
Rapid application development, cross platform support, and true
glue-ability
of pre-existing components have been some of the features
that have aided the acceptance of the more widely known script languages
to date. Having a "killer application" can also help to bring a
language to the attention of others. (Being first, or at least early,
in the *scripted* cgi processor helped Perl, and, in my opinion, Zope
may have done this for Python, which had previously remainded fairly
obscure.)
I suspect that the true, untapped, growth market is the "programming"
language for non-programmers. Making the computer more accessible to
the techno-phobe is what has driven PC growth ("technophiles" and
gamers
adopted computers much earlier). This concept has been
featured more prominently in the on-line information for REBOL in the
past, but frankly one has to dig a lot more to find "those pages" these
days. Given that bills need to be paid, I can readily appreciate "why"
the enterprise-focused, revenue-generating aspects are prominently
displayed. But I am really disappointed to see that the message that
REBOL might be a language-of-choice for non-programmers given its more
natural
linguistic appearance. And this is the juncture where my
inability to understand the developing product line becomes a problem: I
would imagine that these enterprise-level programs will allow for
non-programmers to take more appropriate control of doing the little
things, in the same way that the macro languages helped the
non-programmers take more control of their word-processors, etc. And
here is where I think the real growth potential is for the language at
large: quicker and more seemless development for the enterprise by the
developer with easier access to the good stuff by the non-programmer. A
marriage made in "heaven"; possibly the killer application for REBOL.
VBScript does NOT do this for Microsoft's enterprise-level software in
my opinion, and is hardly approachable by the mere mortal, and there is
*no way* that Java does this, nor the Java-like C# (sorry Redmond).
Microsoft's enterprise-level software will continue to only be
approachable by way of "real" development by "real" programmers for the
foreseeable future. That is not necessarily true for REBOL, in my eyes
as a non-professional "hobbyist programmer."
I truly don't "know" what is right for REBOL. I like it; it speaks to
me in a way few languages have. I don't understand the currently
proposed direction for the various evolving products, and I think Petr
spoke for me when he said that this prospect makes people nervous. I
also don't really know what is the best marketing approach is for REBOL,
but I do know that in considering basic principles of human existence,
that as the product is being marketed currently, REBOL will need to
somehow pay the bills for RT, or both may die on the vine. This
prospect would understandably make developers and RT staffers both
nervous. I believe that this is the reason that a few toes were
inadvertantly stepped on of late. It is understandable.
Here are my two suggestions. First, I believe that RT in its leadership
role likely "owes" its list-members/language-followers a little more
idea of where it is heading. In the medical profession I learned long
ago that honest communication goes a long way toward improving
understanding. Being evasive or being silent only breds mistrust,
misunderstanding, and ultimately disloyalty.
Second, I believe it can really help to occasionally take a huge step
back and try to see the situation from a different perspective. I
sometimes do this by using the Internet as my vehicle by doing a sort of
stream of consciousness websurfing (nothing metaphysical really being
implied). This morning I did this and ultimately stumbled across an
interview with Larry Wall (Perl founder) from last year. I believe most
would agree that he is articulate, humorous and insightful (far more
than I am and in all three categories). Without further commentary I
offer the following link as additional food for thought on these issues
presented in this thread:
http://www2.linuxjournal.com/cgi-bin/frames.pl/lj-issues/issue61/3394.ht
ml
Have a nice weekend, all.
--Scott
[12/33] from: drebol:mindspring at: 17-Feb-2001 15:56
----- Original Message -----
From: <[Robbo1Mark--aol--com]>
To: <[rebol-list--rebol--com]>
Sent: Saturday, February 17, 2001 4:55 AM
Subject: [REBOL] Re: /View as a Product
> Holger,
>
> Iam honestly sorry as I seem to have offended you somewhat.
>
> A couple of points I'd like to clear up.
>
> 1. I Love REBOL & wholehearted support REBOL Technologies.
>
> Secondly If you remember the Slashdot articles about REBOL, we got
absolutely
> panned by that crowd, they beat us over the head with the open source
stick
> and "SOME" made valid points regards REBOL versus PERL, PYTHON & RUBY etc.
me...Please don't hate me, this is only thoughts out loud
Don't be fooled. Each of these products were not open source when created
by individuals with focus in there beginnings. At first they were simple
but unique in there power to make others want to modualize them in there own
way. Everybody wanted
to add the missing important stuff and the person with focus could'nt focus
any longer so they found a way people could keep adding while there name ws
still on it, hence we get the open source theory.
I want REBOL to succeed massively however to get certain
> sections of the software community to even consider it you have to be open
> source, hence to help REBOL make headway in these areas Open Source Code >
me...
Open Source Code does not make programs famous, being able to work on the
most computers makes the compiled language famous (C/C++,Cobol,VB,Java, in
schools)
(wich means nothing for the internet world) and in the end being able to
been seen by most client browsers makes noncompiled languages and
components famous, (flash, javascript,activex, beans,xml,html,etc... on
client)
Now look at whats famous for the net and why? You don't have to change a
thing to get them to work, but just download them and write to it.
> It's all about choice, Just now we have only one choice REBOL versus the
REST.
> We have more to worry about in Java, MS Dot Net, Python, Perl etc. Let us
> take on those people, not each other.
>
me...
You don't have to take on no one if your stuff works in people browsers.
It seems Rebol must be taking a niche market approach (set-top, wap,
telephony,messaging through netwworks) wich is harder to deal with than the
net because those markets don't exist right now(they do for the client in
the browser).
They can't find out how to communicate outside of there selfs,could rebol
save them?
Possibly, but only with Rebol/Express. Chase the new money baby if you can.
If it doesn't work, you sell out and open your source, but you better have
an ace up your sleeve, THE BROWSER PLUG-IN, cause if you don't the buyers
even won't support what they bought from you either because your language is
a conflict of interest.
No ones asking for it because its not in there browsers, and thank God
because there crappy stuff is. But don't worry, this is just my personal
thoughts of 2 cents worth.
[13/33] from: karlr20:home at: 17-Feb-2001 16:49
Heh heh, I was wondering when Mark's OSCAR posts would provoke a response
from people at REBOL Technologies (RT). As a suggestion, perhaps Mark could
limit his OSCAR recruiting efforts to a monthly status report on this list.
For the past four years I've been using Trolltech's Qt GUI toolkit
(http://www.trolltech.com) for my user interfaces. Even though it was not
open source when I started using it, all source code was provided and it was
free for free products. If either of those conditions had not existed I
would not have used it. Since then I have had the companies I have worked
for purchase multiple licenses. Trolltech is a successful company (they've
just opened a new office in the states and raised the price for a Windows
license to almost 2 grand!) and now their products are open source.
I hope RT will pursue a similar course of action.
Thanks for your post Scott (Jones?). The interview with Larry Wall is a good
read. As a Linux user for the past five years I know the value and security
of open source.
REBOL, to be fully realized, will become a foundation technology
(infrastructure) for larger systems. In the interview Scott mentioned, Larry
Wall says "What I do see is a growing recognition that anything resembling
large-scale infrastructure ought to be open source". I agree that
infrastructure is best when it is 'owned' by everyone. There is little worse
than being forced to use inadequate tools (Microsoft anyone?) or seeing
valuable tools die (the sad fate of the Amiga). Open source insures us
against both of these extreme technological maladies (did I make that up or
did I read that somewhere?).
Hi Volker Nitsch. You seem to be a little confused as to what open source
means. Where is the audio in REBOL? Where are the fast vector-graphics
(Flash)? Where is the fast GUI with clipboard/DND? Where is 3D?
If I had the source code to REBOL, I could probably add audio for OSS (unix)
in a few hours. In a few weeks I could add model! and animation! datatypes.
If I don't have the source and the ability to add datatypes to REBOL I'm SOL
and I wait with everyone else for RT to implement it. I am frustrated about
not being able to use REBOL where I would like to because of the restrictions
(e.g. no system calls!) RT places on it.
Before RT had funding, I recall they were asking for donations.
I would never give money to someone so they can develop *their* product. If
it had been an open source venture where they were developing a product to be
released to *me*, I would have gladly given upwards of $1000.
And now for some less focused thought.
Open source is very zen. Everyone owns it yet no one controls it. It can be
nurtured and harvested to provide income for the care-givers. It can be
focused and shaped to arcane purposes. It can be viciously hacked!
REBOL hints at truth
sequestered on its island
openness awaits
Cheers,
-Karl
P.S. At work I'm writing a REBOL-like scripting language for video games. My
company is very pro open source. Keep your fingers crossed!
[14/33] from: robbo1mark:aol at: 18-Feb-2001 5:01
Karl,
I couldn't have put it better myself.
Open Source provides software users with Freedom, Choice, Security &
Empowerment.
These are all pretty important wouldn't you say?
REBOL products are great let us use them and learn from them.
Mark Dickson
[15/33] from: jeff:rebol at: 18-Feb-2001 19:26
Howdy, Mark:
> Open Source provides software users with Freedom, Choice,
> Security & Empowerment.
>
> These are all pretty important wouldn't you say?
I don't think anyone's arguing against open source at all.
I think the question is really one of scruples and tact.
Sincerely,
Jeff
[16/33] from: dvydra2:ya:hoo at: 18-Feb-2001 21:07
Karl,
You make a very convincing argument for REBOL to go
open source. They should adopt a licence where
corporations will have to pay, but individuls will
not.
Lets hope for the best.
Regards,
David
--- Karl Robillard <[karlr20--home--com]> wrote:
> Heh heh, I was wondering when Mark's OSCAR posts
> would provoke a response
<<quoted lines omitted: 87>>
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
=====
please reply to: [david--vydra--net]
[17/33] from: jeff:rebol at: 19-Feb-2001 7:39
Howdy, Mark:
> 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!
No, you're just being a pushy religious person. You'd
prefer to use the forum that REBOL Tech. provides to
proselytize your religion, instead, of say, posting a cool
script, helping a newbie, that sort of thing.. Just because
your religion is totally righteous in your eyes doesn't mean
you have to beat everyone over the head with it day after
day. Some people may not, for what ever reason,
particularly agree with your creed, regardless how correct
your creed is. The scrupulous and tactful are considerate
enough to grant their fellow humans freedom from
religion. If not, then crusaders away! :-)
Now then, I don't know if it counts for a halo of some kind
in your religion, but I, personally, have submitted C code
for inclusion in Gnu Emacs, contributed open source code to
the dict project (a project, if you are unaware, which was
founded by one of the original Linux Developers, Rick
Faith). Of course, I've also produced piles of royalty free
and, in fact, license free REBOL scripts for the enjoyment
and use of any who might enjoy them or find them useful.
So, you don't need to preach to me about open source.
Well, I do hope my message here does not offend you, Mark
Dickson, but I also hope it's not just another vehicle for
you to launch into another sermon. (-: Somehow I knew that
if anyone argued with your means, you'd only respond by
arguing their ends. :-)
Cheers and all the best--
Jeff
[18/33] from: phil:harris:zope at: 19-Feb-2001 15:54
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
<<quoted lines omitted: 7>>
> >
> >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.
<<quoted lines omitted: 6>>
> >
> >/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
[19/33] from: robbo1mark:aol at: 19-Feb-2001 11:26
Jeff,
Sorry I do not want to preach, sorry if it has come across that way. Yes I do feel strongly
about the benefits of "My beliefs" but I would to think Iam tolerant of other "creeds"
as well.
I promise I will try to be a less "pushy" list member at this excellent forum, it just
frustrates me that I see various people making the same comments and complaints again
& again but don't feel they can do anything about it, but they can, but hey we've been
over that already.
My humble apologies, hope Iam everyones friend again!
Mark Dickson
In a message dated Mon, 19 Feb 2001 11:12:18 AM Eastern Standard Time, [jeff--rebol--net]
writes:
<<
Howdy, Mark:
> 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!
No, you're just being a pushy religious person. You'd
prefer to use the forum that REBOL Tech. provides to
proselytize your religion, instead, of say, posting a cool
script, helping a newbie, that sort of thing.. Just because
your religion is totally righteous in your eyes doesn't mean
you have to beat everyone over the head with it day after
day. Some people may not, for what ever reason,
particularly agree with your creed, regardless how correct
your creed is. The scrupulous and tactful are considerate
enough to grant their fellow humans freedom from
religion. If not, then crusaders away! :-)
Now then, I don't know if it counts for a halo of some kind
in your religion, but I, personally, have submitted C code
for inclusion in Gnu Emacs, contributed open source code to
the dict project (a project, if you are unaware, which was
founded by one of the original Linux Developers, Rick
Faith). Of course, I've also produced piles of royalty free
and, in fact, license free REBOL scripts for the enjoyment
and use of any who might enjoy them or find them useful.
So, you don't need to preach to me about open source.
Well, I do hope my message here does not offend you, Mark
Dickson, but I also hope it's not just another vehicle for
you to launch into another sermon. (-: Somehow I knew that
if anyone argued with your means, you'd only respond by
arguing their ends. :-)
Cheers and all the best--
Jeff
[20/33] from: cbayona:operamail at: 19-Feb-2001 11:06
Saying something don't make it so, you can claim that Oscar is not competing with Rebol
all you want, but that is precisely what Oscar is doing.
Anyone is free to make any product they want, it's a free country, but it's tacky to
try to make a copy of Rebol then advertise the fact in THEIR mailing
list.
The people at Rebol have spent a lot of time and money to create Rebol, and they have
provide a lot of their products to us for free to boot, maybe it's a
crazy idea I have, but I think they are entitled to make a profit from their efforts.
Enough said, by me anyway.
Cecil Bayona
[Robbo1Mark--aol--com] wrote:
>CECIL,
>
>do you actually read what has been said.
>
>OSCAR does have it's own mailing list, I think the problem is that perhaps there may
be the opinion that there is "TOO MUCH" reference to it!
>
>However I re-assert, OSCAR is NOT my project, I do not see it as COMPETING with REBOL
rather COMPLEMENTING it!
>There are 67 members there who at least must have an interest in REBOL & open source.
>
>Surely being on one list and discussing the other is not wrong in certain contexts?
OSCAR does not preclude REBOL in anyway, I would like to think the
reverse is true!
>Check your facts before you speak buddy!
>
>Mark Dickson
>--
>To unsubscribe from this list, please send an email to
>[rebol-request--rebol--com] with "unsubscribe" in the
>subject, without the quotes.
>
1-`````````````````````````````````````````````````------``````
[21/33] from: petr:krenzelok:trz:cz at: 19-Feb-2001 19:10
----- 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:
<<quoted lines omitted: 6>>
> >
> >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.
<<quoted lines omitted: 6>>
> >
> >/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
[22/33] from: robbo1mark:aol at: 19-Feb-2001 13:47
CECIL,
How exactly does a yet to be released / fully developed open source REBOL
compete
with REBOL/Core and possibly also REBOL/View which are free in
price anyway, and with /Core also freely distributable.
Would a future OSCAR damage REBOL Technologies commercially by taking away
any revenue from /Core and /View? clearly NO!
So rather than being a competing product it surely would be complementary
offering source code availability for those who need it.
Also when did I ever say REBOL were NOT entitled to make a profit from their
activities?
Iam very grateful to REBOL for all they have provided for free, I genuinely
hope that their commercial offerings for enterprises are very successful,
that way REBOL succeeds and grows, and Carl, Jeff & Holger and the rest of
the REBOL team are financially rewarded for the sterling work they do.
Sure I have differing opinions about the best way to develop the foundation
technology but we've already discussed that ad naseum.
I WANT REBOL TO SUCCEED.
Surely we ALL want that?
Mark Dickson
[23/33] from: gchiu:compkarori at: 20-Feb-2001 12:29
> However I re-assert, OSCAR is NOT my project, I do not
> see it as COMPETING with REBOL rather COMPLEMENTING it!
> There are 67 members there who at least must have an
> interest in REBOL & open source.
Hi Mark,
I am sure the problem is that you are using RT's list to
promote your own/others cause which ultimately may lead to
loss of revenue for RT. ( On the other hand it may lead to
increased revenues - but who is to know? ) I'm in favour of
Open Source, but not if it leads to reduced development by
RT. They've got enough competitors with NQL ( see Jan Dr
Dobbs ) and others coming.
Some companies have as part of their licensing agreements
the condition that the user does not reverse engineer their
products. I haven't read RT's license for sometime, but
would be suprised to find it missing.
--
Graham Chiu
[24/33] from: dvydra2:yaho:o at: 19-Feb-2001 17:58
Good question. Is REBOL syntax copyrighted?
--- Graham Chiu <[gchiu--compkarori--co--nz]> wrote:
> > However I re-assert, OSCAR is NOT my project, I do
> not
<<quoted lines omitted: 31>>
> [rebol-request--rebol--com] with "unsubscribe" in the
> subject, without the quotes.
=====
please reply to: [david--vydra--net]
[25/33] from: robbo1mark:aol at: 19-Feb-2001 3:08
Jeff / Holger
Sorry if you feel I've either been unscrupulous and untactful - or both.
Personally I find this a little upseting and offensive, but that aside,
I don't agree with some of your points, I feel all I've did is try to
discuss REBOL in a wider context, sure I've promoted OSCAR but I've NEVER
said leave this list & join ours, don't use REBOL come and develop OSCAR,
I've never tried to lure anybody / developers away from REBOL ( a useable
& fantastic working product ). When did I ever say these things?
The main reason for OSCAR and most of my posts is that I see people on this
list asking for this feature and that feature, wishing REBOL could do this or
dp that,
feeling frustrated that bugs or there pet favourites and attended to.
Rather than continually pester you guys and REBOL Technologies Inc. who
rightfullly have your own commercial priorities and views of how and where
REBOL should develop, rather if they really want these things badly enough,
why not actually DO something about it and help THEMSELVES.
I've never said don't use REBOL, frankly that is absurd. I merely gave my
opinion on what might be a better framework for REBOL to develop in.
Is this list for the REBOL community at large or not?
Or is it a REBOL equivalent of Pravda, where only the party line is presented
and applauded?
Cheers,
Mark Dickson
[26/33] from: robbo1mark:aol at: 19-Feb-2001 8:38
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 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
[27/33] from: cbayona:operamail at: 19-Feb-2001 8:56
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
<<quoted lines omitted: 4>>
>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
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.
[28/33] from: robbo1mark:aol at: 19-Feb-2001 10:36
CECIL,
do you actually read what has been said.
OSCAR does have it's own mailing list, I think the problem is that perhaps there may
be the opinion that there is "TOO MUCH" reference to it!
However I re-assert, OSCAR is NOT my project, I do not see it as COMPETING with REBOL
rather COMPLEMENTING it!
There are 67 members there who at least must have an interest in REBOL & open source.
Surely being on one list and discussing the other is not wrong in certain contexts? OSCAR
does not preclude REBOL in anyway, I would like to think the reverse is true!
Check your facts before you speak buddy!
Mark Dickson
[29/33] from: rebol:techscribe at: 21-Feb-2001 0:00
Hi Paul, Chris,
Chris wrote:
> Paul Tretter wrote:
> > /View that way RT makes profits off of /View scripts that customers want to
<<quoted lines omitted: 4>>
> to a minimum or the delay while loading, decompressing and starting
> the interpreter will affect response times.
1. Can /View start up without XWindows libraries being present on the
hosting machine?
2. Can it reasonably be assumed that most Linux (xxxBSD) Web hosting
machines on the net will have XWindows libs installed (what for?).
If the answers to 1. and 2. are both "No" then in IMHO it is not
feasible to use /View as a CGI interpreter.
/View would have to be able to determine if the required XWindows libs
are available, and, if not, start up in /Core mode without attempting to
load XWin libs, to be useful as a CGI Interpreter.
Take Care,
Elan
[30/33] from: ptretter:norcom2000 at: 21-Feb-2001 9:13
Elan,
I agree, that is why in a later email in regard to responses like
yours I thought it would be nice to separate the functionality
of /Core and /View maybe via a switch that could unset most of
the /View components (bear with me) so that /View is started with for
example "rebol.exe -c" which would basically be /Core functionality
for cgi applications. Either way I was just trying to express what I
still feel is the future of /View.
[31/33] from: rebol:techscribe at: 21-Feb-2001 11:55
Hi Paul,
I agree with you that a switch could be used to switch off the X
dependency. This could be the default for the CGI switch (which I
believe is what you are saying).
Take Care,
Elan
[32/33] from: holger:rebol at: 21-Feb-2001 13:52
On Wed, Feb 21, 2001 at 11:55:22AM -0800, Elan wrote:
> Hi Paul,
>
> I agree with you that a switch could be used to switch off the X
> dependency.
Unfortunately this would not work. The X dependency of View is not caused
by anything View does, but by the fact that the linker creates references
to X libraries, i.e. the error messages if you don't have X installed
are not displayed by View, but by the Unix loader, long before View is
really started and has a chance to parse command line arguments.
It would be possible to work around this by using dynamic library loading and
linking, but that creates a flurry of other problems (compatibility, versioning
etc.), so we would rather not do it. The best solution is to keep Core and
View separate.
--
Holger Kruse
[holger--rebol--com]
[33/33] from: rebol:techscribe at: 21-Feb-2001 16:22
Hi Holger,
well, I was going to propose dynamic library loading. But you beat me to
it. Guess it won't work. (Personally, I'm quite happy keeping the CGI
overhead low and using /Core. What's more, I use /Core most of the time
anyway. Haven't even installed the extended expiration version of /View
yet. But that's not to say that I'm not interested in /View. /Core is
just a better fit for what I'm currently doing).
Take Care,
Elan
Holger Kruse wrote:
[..]
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted