Well, this could be interesting...
[EMAIL PROTECTED] wrote:
>[EMAIL PROTECTED] wrote:
>> /View currently is not a separate module. A modular approach
>> is certainly an option for the future though,
>
>It shouldn't be an option. It should be a must have. If we
>will not modularize and build upon one rebol.exe/core/kernel,
>then I still don't understand the picture :-) ... which is
>happening quite often in regards to the computing industry :-)
It just occurred to me, this could be a solution to many of
the problems that had been brought up on this list recently,
including the money and distribution problems. Pardon me if
some of this stuff is obvious - I need to provide context.
Keep in mind that we want REBOL Technologies to make money, so
that they won't go out of business and stop making REBOL. We
also want third-party developers (that's us) to also be able
to make money with REBOL, so that we won't be forced to use
lesser languages to enable us to eat. Equally importantly, we
want the work done by the REBOL community to be able to be
shared by the REBOL community, for the betterment of all (or
for those less community-minded, for the betterment of the
code through more extensive testing, and for the reduction of
work that comes from code and idea reuse).
Given that, here's my idea...
Have REBOL be organized into a core program and several modules.
This could take be done as:
- One core REBOL, /Core, with a module interface, and several
modules that provide extra functionality. You could put all
of the system-specific stuff in modules, like /Command or
/Apache, as well as stuff that has unnecessary overhead for
some purposes, like /View. RT would then give away /Core, and
sell and give away modules. This is simple for RT in some ways
(one code base) and us (one /Core API), but has disadvantages
for RT (less flexible = less portable) and for us (one code
base = no Palm/embedded or massively parallel servers).
- Have multiple core REBOLs with a common module interface and
mostly common capabilities. Give some away (/Core, /Browse),
sell others (/Command, /Apache, /Netscape). Make sure that
/Command hooks into the local scripting architecture (Win32
ActiveScripting, AppleScript) if any. Have multiple modules
that can be added on to any core, where relevant. Give some
away (/View, /Sound), sell others (/DB, /SSL, etc.) where
appropriate. Bundle modules with REBOL distributions, giving
them away or charging appropriately. I like this way better.
It allows for more flexibility while keeping the basic idea
the same. It can even be implemented in such a way that all
extra features of the more advanced cores can be accessed as
internal modules, either logically or actually (ever see the
plugin architecture of BO2K? - very REBOLious).
The general pricing strategy would be to give away the safe,
portable, client-side stuff, and sell the non-portable, unsafe,
server-side, or patent/license/royalty requiring stuff. Hook
people with the safe stuff, they'll want to do more. By this
token, RT should charge somewhat less for generally useful
REBOLs like /Command, more for /MassivelyParallelEvilServer.
Hey, this strategy works for drug dealers, why not REBOL? :)
RT can even make deals with various platform/OS manufacturers
to add great platform-exploiting modules, or at least to give
us the info to build our own. Some companies will pay _you_
to exploit their platforms.
This pricing strategy would solve the distribution problem by
allowing most client apps to be distributed without royalties,
but making sure that RT can make enough money off the advanced
stuff. This gets REBOL widely distributed, which expands the
market for modules and more capable REBOLs.
Definitely make the module API public, and give us the ability
to write modules in either REBOL or native code. This will take
some of the pressure off RT to get X feature added - you can do
it yourself. This will also create a module market, for those
of us who need monetary motivation to improve the language. RT
can even make money by making commercial licensing of native
APIs cost (or be bundled with core REBOLs that cost), while it
keeps REBOL language (and non-commercial use of native) module
APIs free to encourage third-party development.
If the REBOL-language and native module APIs are similar enough
semantically, I could even adapt the Squeak-to-C compiler to
create a REBOL-to-C compiler for a semi-static REBOL dialect.
How would you like to write your own natives, actions and types
in REBOL?
Now, there are definitely problems with this strategy, but you
all will probably be better able to express them than me :)
I'm just throwing this out to start a discussion.
So, what do you all think? REBOL Tech. people, chime in too!
[EMAIL PROTECTED]
