[REBOL] Re: even further ... Re: Introducing REBOL/Base - FAQ
From: pwoodward:cncdsl at: 3-Oct-2002 13:58
----- Original Message -----
From: "Petr Krenzelok" <[petr--krenzelok--trz--cz]>
> Are you sure the idea is new? :-) I would even go further, stating that
> REBOL/Base should become real kernel, even for native mode stuff. Rebol
> components - not quite an new idea - we talked about it here several
> times already. I think that having everything in one .exe is not
> maintainable for Rebol future direction. What if there is need for .mp3
> or .divx support? What if such support would require 300kb space? Will
> RT add it, or will RT say that it will not be added, as it would add
> significant increase to executable size?
Some bits-and-pieces are already located in .r file, but most of the stuff
is "encap"ed into the main .exe. But, you're right, when you start looking
at multimedia codecs it would be very handy if those could be located
outside of the main executable. If small enough, it makes sense to build
them in - but when they get large (or there are a lot of them) it would
probably make sense to externalize them in some fashion.
> If I understand it correctly, rebol components as can be seen in system
> structure, are separated already ... what if I am not interested in
> /odbc, /library, /sound, etc? Why should those be in my rebol.exe and
> push my clients to download them if not needed? OTOH there should be
> some option to specify something like:
>
> if not component? 'sound [go-download-it!]
>
> Such aproach would even imo better allow RT to structure sales, prices,
> create some package combinations etc.
I somewhat agree with this. I think the standard distribution should
include as much functionality as possible (the current configurations are
pretty much ideal). However it might make sense to defer loading of some
modules until they are actually needed. Not so much a "download" of the
module, but rather a delayed loading of modules which are already resident
on the system running REBOL. The load and install of modules (sound, odbc)
should be transparent to the script writer - no need to "include" or
import
the library. The first time their script hits HTTP, the
appropriate network protocol is loaded. This makes the first time you fetch
a web page take a second or so longer, but subsequent calls would use the
memory resident module.
Another change that might work out well is a config.r file that allows you
to specify which modules to pre-load on startup. If you know you're using
VID components alot, or ODBC, or whatever, load them right away. REBOL Tech
could include a number of defaults, as well as some sort of "download"
mapping for modules which are not part of a standard install. So, MP3, or
other codec type functionality could be downloaded if needed...
> If there is still someone scared of so called .dll hell, so RT
> introduced Rebol preprocessor to us. Simply put - create package of
> stuff you need and distribute as one file, if you need ...
Essentially I think the directory structure of the REBOL install needs some
strengthening. By adding a few more directories to manage
modules/components. RT could have a standard installation directory
structure that is created. By externalizing some components, they could be
updated seperately - /Core essentially becomes the standard library (much
like Java).
/Base becomes the language processor, and /Core is an overlay on top of
that. The /Core library mapping could be provided by a single .r file which
would provide the "flavor". It would name the standard protocols and
extensions, but loading the code could be deferred until such functions are
actually called by a running script.
I would definitely like to avoid include/import type statements for scripts
for /Core functionality though. Extended, non-core functionality certainly
could use a "requires" or other directive. Additionally something like
requires
could be used to specify a version of /Core functionality.
Another thing that might be useful for RT is to consider the /Core flavor
definition to include some deprecation mapping. If certain types of
features are to be retired (do to a poorly thought out initial
implementation or whatnot) then they could be put into a deprecated list -
still available, but a script could generate "deprecation" warnings then.
And, eventually maintainers could update their script.
I know this probably sounds like a lot - and a lot of it is inspired by Java
and .Net. While REBOL may do a lot differently, and more easily than those
two component models, it doesn't mean that we can't learn from them.
- Porter
