R3.0 Plan for April 2009
First, let me say that we didn't follow the March plan that we
outlined last month.
Project review
About mid-March we took a break and spent time on project management,
reevaluating and reorganizing the detailed project list.
What became obvious was that several lower level subsystems and
functions should take priority over those I outlined in the March plan.
For example, I've been very interested in seeing the next steps happen
on the GUI system, but various sub-projects are necessary in order for that
to happen. We needed proper support for decoders (codecs) for image
loading, and module support for proper structure and isolation of the
GUI's internal functions. (For example, the system/view object isn't
supposed to be the global environment of the GUI system like it was in
R2. The R3 GUI must exist in its own name space.)
In addition there are subsystems like security that are rapidly
growing in importance as more developers download R3 and try out
scripts.
So, together these create a development path that must be pushed to
completion as quickly as possible, and that's really more of a focused
goal now.
During March:
- Fixes to developer file-sharing overlapped into the first week of March,
but we got it released! We uploaded source code modules for R3
mezzanines and the current R3 GUI system. It was encouraging to see
developers download code, made useful changes and fixes, and submit
them back into the system. All of that operating under REBOL scripts,
with R3 processing it on the client side.
- The submitted changes were integrated into new releases that were
published toward the end of March. Sources within DevBase (RebDev) were
accepted (tagged) to make them official, and the project is building
momentum.
- The module mechanism was released, including the new IMPORT function,
proper isolation with changes to the RESOLVE function. The system
object's module-path is now used for module searches, and programs
loaded that contain NEEDS fields will preload their necessary modules,
including version checks and SHA-1 hash validations of module contents.
Finally, a modules section was added to the R3 Docs Concepts area.
- A big milestone for us personally was running the first R3 CGI script
on our main web server. This allows us to begin building backends now
in R3, allowing us to build some testing time under those environments.
- The R3 codecs (media decoders and encoders) subsystem was added and
initial releases have been made with codecs for JPEG, GIF, PNG, and
BMP. More work is still needed for optimizing and allowing special
options and modes, but it's now at least something real.
- The DECODE, ENCODE, and ENCODING? functions were added to support
the interfaces into the codecs, and LOAD and SAVE were updated
accordingly. You can once again LOAD a jpeg locally or over the
net, and this is also important for the GUI and applications.
- The ASSERT function was added, a very useful way to validate
conditions and datatypes, and documentation for it was added.
- Various important enhancements where made to LOAD, including
loading of blocks and the /next feature, often used to translate
REBOL in a stepwise fashion. Also, TRANSCODE was update to support
these changes, with /next and /only refinements.
- CONSTRUCT was improved to safely handle objects like REBOL/headers
as well as to allow a raw mode via the /only refinement.
- A better search mechanism was added to embedded HELP that gives
users a better way to find related functions and features. The
HELP /doc refinement was also added as a shortcut to the official
online documentation pages.
- Builds were made for R3 Core on OS X PPC and also changes were made to the default Linux builds. This change allowed us to run R3 now
on all our primary servers.
- More was done to improve the R3 documentation. Various sections were
added, updated, and clarified. There's still a lot more to do. If you
look at the timeline, the docs are by far the largest subproject
remaining.
Goals for April
Right now, I have one primary goal for April: To get the detailed
project list published, so you can review the list for yourself, make
comments, and hopefully find ways to contribute toward its progress.
At the top of that list is the project that I think must happen next:
security. Although certainly many of developers know how to wrap R3 in a
3rd party sandbox for testing, it's not our intention that every user
should need to do that.
With more and more R3 programs, demos, and shared modules becoming
available, the need to integrate security back in the core system has
become even greater. This is a big step toward becoming Beta.
11 Comments
|
