Comments on: Quick Update: Same Direction, Same Goals
I wanted to write a quick memo to help clarify the current priorities - especially in reference to The REBOL Week note about "changing directions a bit".
Nothing has changed.
Our direction is still the same. We do many things at the same time - in parallel. Here is a summary:
- Build REBOL 3.0
Good progress is being made design of GOBs (optimized graphical objects) and REBOL database/indexed files. With regard to the latter, we are examining the possibility of incorporating the lower layers of the SQLite database (the btree and paging system). Then, on top of that we would provide a direct REBOL DB dialect for implementation of all DB methods. The goal is to add all of this with minimal impact on the overall size of REBOL.
- Improve REBOL 2.6
As you know, our goal was to keep updates coming more often, but we've done a poor job on that due to allocating our resources toward REBOL 3.0. We can't keep delaying 2.6 updates. Fixes are needed, so the project priority is increasing.
- Improve the documentation
This includes new REBOL tutorials as I mentioned a few weeks ago, but also the dictionary, manual chapters, and much more. I am convinced that we need a wiki approach to those docs, but the bigger question is what is the best wiki?
- Improve the REBOL.com website
Some of you may have noticed that the content of various pages has been updated - such as the What is REBOL? page.
The goal is to have nearly all pages updated by the time REBOL 3.0 is released. We will also be modernizing the look of the site.
So, we are not changing directions. I apologize if it appears that way - because we simultaneously develop many areas at the same time.
PS: I do admit that we have shifted the release of a few earlier projects like Rebcode, REBOL/Services, and Altissimo (AltME maximo). I assure you, those have not been forgotten! They will play an even larger role within the scope of REBOL 3.0!
16 Comments Comments:
Henrik
5-Nov-2006 14:38:44 |
what is the best wiki
Couldn't it be done very simple with REBOL and MakeDoc 2? I would imagine that using MakeDoc 2 syntax with a simple form that on submission generates an HTML page and then logs the time of the update, the contents in full text, the name and IP of the author and reason for editing in a block which is then molded and saved to disk.
This allows easy roll back by just pointing at a specific point in the log. A new HTML page could be generated every time you do a roll back via a roll back form. The page itself would be static.
Disadvantages:
Storing differences would be an issue as well as branches in the log. Large documents could be difficult to edit. | rebolek
5-Nov-2006 15:09:32 |
Henrik,
I agree we should use something REBOL-based, MakeDoc2. It can be probably combined with gabriele's 'diff from library. differencies can be easily stored and restored this way. I use it for my version management system. | Allen
5-Nov-2006 16:58:54 |
What is best Wiki? Compare them http://www.wikimatrix.org or use the wizard to narrow down based on your prefs. http://www.wikimatrix.org/wizard.php
At the very least, it is a good resource for anyone who wants to write a rebol wiki alternative. | croquemitaine
6-Nov-2006 15:15:58 |
the wiki THE solution to prove what Rebol is about and why not including it in Rebol or Altme functions?
Being user including being member of a community? | Ged Byrne
7-Nov-2006 8:59 |
Don't forget Vanilla:
http://www.vanillasite.at/
For an example of what features a documenation based wiki needs, see PHP based DokuWiki:
http://wiki.splitbrain.org/wiki:dokuwiki | James_Nak
7-Nov-2006 17:46:45 |
I think for marketing reasons it should be a Rebol-based wiki. | Cranky
7-Nov-2006 19:56:13 |
Sigh.
Focus on writing the documents. That is the bigger question. Get all of the information in there-- especially the specs and limitations for each value/datatype. Explain the intent of each construct, its common usage, then its idiomatic aspects, etc. Get it out of the mind of Carl and out into the open.
Keep the content in a neutral format which will let you manipulate it and do whatever you want to do with it.
THEN worry about which wiki.
"Comrades! The revolution will indeed be televised! But first we must solve the problem of building our own televisions." | Ricardo
7-Nov-2006 20:48:40 |
Rebol Open Documents Read/Write
Rather than use existing internet Wikis:
- write documents in Rebol layouts:
- provide a few templates
- include a template with a scrolling pane
- documents are read as a layout, perhaps
in a large pane from the index layout
- use Rebol Services, client and server:
- client requests a document, which can be returned
if edited, to the Rebol server, ready for the next
review and possible edit
- easy for readers to edit text in areas and return them
- images could also be inserted into the layout
- system is an example of applied Rebol scripting,
sort of a Rebol document browser with features that
could include spell checking, searching, cross
referencing
- this proposed Rebol document browser could be opened
from a web page link, and also directly from the desktop
| -pekr-
8-Nov-2006 3:59:25 |
We already have our app, done in View, which allows comments - that app is really nice - it is called Word Browser.
As for web based solution, I am not sure I care enough, but - I would like solution being Rebol based. This whole blog system is very nice example (or RAMBO too) - it does EXACTLY what suits us and what we want it to do. We should use some kind of make-doc3 plus some generators (PDF, postscript, whatever is available). As for comments, I would not complicate it much. I am not sure we need wiki like "Edit" capability either in the beginning.
I would welcome some discussion on Altme, together with Gabriele and Carl, to make some decisions and move forward. New Docs are starting to appear on Rebol.com, I think that we should develop easy, sufficient, Rebol based system, which could be used even by others to write their own docs on their own rebol-related websites. Unified aproach will make it easier for users to navigate thru various available documentations around the web. But let's start with something simple first.
Petr | Maxim Olivier-Adlhoch
8-Nov-2006 15:33:52 |
I agree with pekr, IMHO word browser is ample for REBOL reference documentation.
Just getting this online (in world wide reb) quickly, will at least allow you to get some content. care about improving the presentation later.
all it needs is a way to add/remove tags by the submiter, and the server for categories and status, and then we can filter out based on those tags. 100% generic, simple and effective.
a peer review mechanism can be added so that a vote system can remove some posts for various reasons. any actual removals being handled by a moderator(s)... but again, all that can be added later.
I'll repeat something someone has told me just last week... care not about perfection, until perfection is within reach (so get it out and make it perfect later).
Word browser has been with us for years... imagine how full of usefull knowledge it would be NOW if this had simply been implemented years ago!
many bugs, gotchas, idiosyncrasies would all be there right now.
We can add hundreds of added functionality later, but for us to improve its usefullness, we need actual data to play with! | joe
11-Nov-2006 7:25:13 |
I just wanted to add that the Rebol DB dialect on top of a SQLLite layer would be a huge advantage. Currently, it's hard to build persistent/reliable applications relying on lots of files | Henrik
11-Nov-2006 9:13:35 |
I was wondering if this could be similar to MacOSX's Core Data? This gives you a lot of data persistence handling for free and saves a lot of time.
It would be nice to be able to set a variable and not having to worry one bit about whether it would be saved to disk and have it automatically be persistent across different REBOL sessions. This of course introduces the need for locking, if multiple instances of the same program is running. | Ricardo
11-Nov-2006 22:01:11 |
A Further Comment On Wikis
Might be an idea not to have edit capability.
Periodically, a moderator could review all posts to a
subject and make up a group of documents. All
contributions could be archived where they would be
available to individuals that may want to add some of that
material to their own documentation.
A wiki can be controlled by an individual or group. Not
having edit and retaining all contributions might be a way
of encouraging input from a broader base of script
writers. Basic and obvious issues too obvious for some
might also then be included.
A document writing process might also include the
provision for questions so that more facets of an issue
than those first considered might be explored. Image
support for document inputs would be needed.
The Word Browser is a very useful program and contains
some very interesting script. But, is it a passive
browser - that is, is there the means where a reader may
provide input to the document base (other than comments)?
| croquemitaine
15-Nov-2006 13:43:11 |
java is now entirely open source.so?
Rebol is not a jave clone but incomes of rebol llc come from sales of tools like a compiler for instance.
Danger is now that all langauges not java could be deprived of such sales! | Ged Byrne
16-Nov-2006 10:03:22 |
An important feature missing from Word Browser is Dialect support.
For example, View words feel the same as regular REBOL commands, but they cannot be found in Word Browser.
It would be good to have a resource that covers dialects as well as the core language. | Would be great if Rebol
4-May-2007 20:38:15 |
Wikis are very powerful. It would be nice if Rebol allowed for creating internal wikis ! |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
