 |
Clarifying the Priorities
In a nutshell, the priorities right now are REBOL/Platform and REBOL/Services. Why not REBOL/View, Mac OSX, REBOL/IOS 2.0, and other such changes? Because all future REBOL releases will be based on /Platform and /Services. In other words, when you run REBOL/View in the future, you will actually be running REBOL/Platform with the /View module. When you use it to connect to a Rebsite and upload a script, you'll be using REBOL/Services. When you use a future version of REBOL/IOS, you'll also be using /Platform and /Services. How's that for convergence of products? The first step in making REBOL/Services work well is to get the asynchronous version of REBOL into a stable release. Currently, it's in alpha testing, but so far it is looking pretty good, and it won't be long before the beta is released and you can try it. During this testing period, it will be important to test this new asynchronous kernel really well. Thousands of lines of code have changed, so that will likely create some new bugs. Please test it! Once the async kernel is released, we will be able to release the prototype alpha version of REBOL/Services on top of it. We will provide a simple asynchronous /Services server example and some test code for you to try it out. You can think of this server as the "standard model". It's not critical that your server be exactly the same. It's a starting point. This code will be open source, so you can make improvements, and we hope you will contribute some nice changes and fixes back for the benefit of all developers. It is important for you to know that, in the end, there will only be one official REBOL/Services standard. That's because we want all REBOL scripts to be able to work with just about any REBOL/Service that is out there. Although you know RT is not big on standards other than the definition of REBOL itself, here is a case where being part of the REBOL/Services standard is a benefit to all users and developers. So, this is going to be interesting, isn't it? It turns out that the hardest part of the REBOL/Services implementation is actually the documentation. After all, the code is written in REBOL, which means that the documentation will end up being ten times larger than the source code itself. Before we even do the alpha release, we really want to provide adequate documentation so all developers understand not only the API and the design, but the reasons we made certain decisions, and the big picture... the big plan as well. So, there is a lot of work to do here before release. What is the schedule for the alpha release of REBOL/Services? This month. Our goal is to release it within the next two weeks from the date of this blog. Of course, once we have it released, we will begin one of those self-bootstrapping processes, because one of the very first REBOL/Services will be a service that lets you access the code archive itself, as well as make submissions for changes, fixes, features, tools, and more. I've got to get back to work now. There is a lot to be done. I hope you are finding this blog useful. Are you? Be sure the let me know.
|
 |
Updated 10-Mar-2024 - Copyright Carl Sassenrath - WWW.REBOL.COM - Edit - Blogger Source Code |