Comments on: R3.0 Plan for April 2009
REBOL Technologies

Comments on: R3.0 Plan for April 2009

Carl Sassenrath, CTO
REBOL Technologies
3-Apr-2009 20:08 GMT

Article #0406
Main page || Index || Prior Article [0405] || Next Article [0407] || 11 Comments || Send feedback

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.



3-Apr-2009 18:39:14
... what happened to March Rebin and plug-ins plan? Postponed?
3-Apr-2009 22:23:25
There was no March ReBin plan.
3-Apr-2009 23:00:46
Kaj, there was rebin plan, no? There were 4 items for March - GUI, Rebin, Plugins, Docs -
4-Apr-2009 0:31:45
As for security, here are my comments:

- R2 dialog boxes were sometimes weird - e.g. when your script path was too long, it did not wrap so you could not see, what element you are giving a permission

- Could those dialog boxes be R3 GUI based? I think about the possibility to translate messages on them, but then I fear a bit about possible message injection. Or could such aproach be secured?

- let's extend security model to think about products as browser-plugin, so e.g. to allow to set sandbox size, etc., but maybe it will have to be specifically solved with the plug-in itself?

- I think that as for a security, BrianH will surely have some ideas here :-)

4-Apr-2009 4:15:28
Secure dialogs are easy to fake, so we have to authenticate in a way that can't be manipulated in R3. Think, adding a keylogger (just a single line of code) in the VID style used for the password field. Can styles be protected?

In MacOSX, each password dialog can request system details about where the request comes from and the request will be written in logs. Strictly, you can still fake such a dialog. I don't know how you can visually recognize a dialog under R3, unless you print some kind of visible unique ID in the dialog.

4-Apr-2009 4:22:12
My point is: Authenticating happens at load-time with IMPORT as far as I understand. So what happens when a user navigates ReBrowse to a fake site that pops up a fake password dialog without anything being loaded?

We also need to ensure that a connection is actually secure. Users trust that a browser really is using HTTPS, when the padlock is visible, so we need something similar here.

5-Apr-2009 1:53:15
Maybe adding a SHA1 based checksum system can help to identify manipulations.

Something like a simple "certificate" mechanism.

Overall, I think there is no perfect 100% solution. Rebol is not the main target of bad-guys and it should be safe enough for 99% of all cases.

With this we are still way ahead of others.

6-Apr-2009 2:24:57
When it comes to these 'Requests/Requirements/Bugs/Progress' etc reports, I'm reminded of the need to make this a more visual mechanism, and with the Rebol cgi working, this could be tied to Base, Docs, etc and posted up as a bar chart on the site showing how things are proceeding. As requests in certain modules increases, such as the security issue, these would be reflected (maybe as a bar chart?) alongside other items like bugs, implementations, etc. Displayed in a segmented manner there could be a historical trend, showing how the priorities are being addressed.

Ah, perchance to dream... :)



6-Apr-2009 2:26:46
Would something like this preclude the constant 'What's happening with' and 'Where are we on...' that gets asked frequently?

Barring members of the Inquisition: Would it be useful?



6-Apr-2009 2:54:15
Luis - we will get there. We are progressing slowly, but we are progressing. RebDev chat serves us for chat, filesharing for DevBase purposes already. We are thinking about the ability to link chat topic to CureCode BugBase tickets. CureCode can also generate changelog. It is not automatically linked, but Carl creates changelog on R3 releases page, and I really like it. New docs have their changelog too. I voted for putthing such stuff in fron of developer's eyes.

I even vote to extend console docs, chat, bugs, upgrade, by news, or changes command.

As for charts - it might be preliminary, until we automate most of those things. I want to go even further - once source codes are released, I want to have bounty program, so that userbase could sponsor some developments ...

Brian Hawley
6-May-2009 0:13:09
Is it time for a May plan blog?

Post a Comment:

You can post a comment here. Keep it on-topic.


Blog id:



 Note: HTML tags allowed for: b i u li ol ul font p br pre tt blockquote

This is a technical blog related to the above topic. We reserve the right to remove comments that are off-topic, irrelevant links, advertisements, spams, personal attacks, politics, religion, etc.

Updated 3-Dec-2023   -   Copyright Carl Sassenrath   -   WWW.REBOL.COM   -   Edit   -   Blogger Source Code