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

[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