R3.0 Plan for May 2009
That old expression, better late than never applies to this month's R3 progress report and plan.
During April
I'm not going to review the details of changes and enhancements made during April, because a full log can be found on the R3 Releases page. If you've not visited that page, it's worth looking at because you will see many advancements
Be sure to note the major changes to the system object and in security. In this area, R3 has moved far beyond R2.
In addition during April, we wrote and updated major sections of the new R3 Guide documentation, including the function sections. (But it goes without saying that much more is needed.)
Goals for May
First, we need to take some time out and catch up on bug fixes because the CureCode database is expanding rapidly. We need to "keep it sane" or "tame", whatever.
The goal is to check-off 50-100 tickets a month in order to make decent progress. Of course, there are also "wish list" items, some of which we really need, and others that we must defer to later releases because we have more important, high priority items.
Next, as some of you know, one of the top level goals has been to provide a greater level of external access from R3. That's mainly so you can contribute your own special features without us standing in your way. But, it's been taking some time to make this happen, and it's going to be necessary to divide it into a few stages.
Here is the sequence I want to see happen:
- Codec plugins - A subset of the plugin mechanism (below) that allows you to interface encoders and decoders. There's quite a lot you can do with these; however, they are a static model of plugins, with fewer design dependencies, so easier to release.
- Plugins - These are full-capability plugins, meaning you can provide both lower level C functions as well as higher level REBOL functions, all within the same DLL module. This mechanism has been difficult to define because we want to provide proper isolation between the plugin and the kernel. Or, stated another way: if we do this wrong, we will end up with what is often called "DLL hell" where even minor changes in the kernel over time could "break" some or all of the plugins. I investigated using rebin (REBOL binary format) for the plugin interface; however, it's quite problematic. Rebin is an alternate lexical form for REBOL, good for data storage or exchange, but not efficient for in-memory structures where some degree of data sharing is desired. (For example, you don't want to clone an image each time you want to update it on a display.) The current solution appears to be a middle-ground, a mechanism I call commands that are similar to native functions, but produce a very specific interface frame (function args). If this works out, it may even be possible to replace the entire delect sub-language dialecting method with a more general mechanism that also includes embedded help, similar to functions.
- Host-lib - These are the open-source modules included within R3. For example, the file, TCP/IP, event, and other devices (which support their respective port schemes) as well as the full graphics system. More than half the size of view.exe is within this code base and it provides the only path for good support over all target systems.
- Host - The top level environment for R3, including its bootstrap, argument parsing, console handler, and more. This is also open source to allow us to add OS resource interfaces, build app wrappers/bundles, embedded boot code, to name a few of the possibilities.
Not all of this can happen in May, but we need to make some level of progress on it in order to get the developer-base up to speed and moving forward in parallel to core-level development.
[Learn more about REBOL3]
5 Comments
|
