Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

/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:yaho:o 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:yah:oo 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