Comments on: 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 Comments:
-pekr-
3-Apr-2009 18:39:14 |
... what happened to March Rebin and plug-ins plan? Postponed? | Kaj
3-Apr-2009 22:23:25 |
There was no March ReBin plan. | -pekr-
3-Apr-2009 23:00:46 |
Kaj, there was rebin plan, no? There were 4 items for March - GUI, Rebin, Plugins, Docs - http://www.rebol.com/article/0399.html | -pekr-
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 :-) | Henrik
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. | Henrik
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. | Robert
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. | Luis.
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... :)
Cheers,
Luis.
| Luis.
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?
Cheers,
Luis.
| -pekr-
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.
|
