Comments on: About Priorities...
From recent feedback questions, I'm concerned that our current development priorities may not be well understood. To help clarify our focus, a summary was posted (obsolete now).
I know that some of you think that we "jump around" between projects. I think it is important to understand that RT splits its resources between research and development (R&D). Sometimes we focus on R. Other times we focus on D.
For example, projects like Rebcode (REBOL VM) were more research oriented. It was an interesting project, and we think users also learned a few things about the possibilities. It is likely that rebcode will be added to a future release of REBOL, but we're only going to do that if we hear that developers really want that capability.
Another example was the REBOL web browser plugin. Back in 2004, we thought running REBOL within the browser was an interesting research project, so we built a prototype. However, upon release, we received so little interest and feedback from developers, that we decided not to pursue the concept further. Then, at the 2005 developer's conference, we discovered to our surprise that developers did want the browser plugin, and that's why we resumed with the project this year and hope to have a final release for you soon. Also, the browser plugin will be a primary feature supported by REBOL 3.0.
I should also mention that there are other market forces that have a strong influence on our development path. I have a model in my mind for what I want REBOL to become and where I want to see REBOL gain adoption and market share. I spend a lot of time studying and considering the long term trends of the Internet, where it is headed, and how REBOL can play a part in that future. Such things will definitely have an effect on development. REBOL 3.0 is a prime example.
Finally, there is one more thing to consider. REBOL 3.0 is designed to allow plugin modules. This means that certain REBOL features may be made "external", and that means your priorities and our priorities can be different because you'll have a good way to extend REBOL. If you need a feature, you can add it. For instance, if you want VOIP, then add that module to REBOL. It is our hope that in this fashion developers will contribute a wide range of useful enhancements.
Well, that's it in a nutshell. If you have a question, please ask (via public comments or private message if you prefer).
10 Comments Comments:
Brian Hawley
8-Aug-2006 1:13 |
Well, let me be the first here to stand in favor of Rebcode. Although there won't be as many Rebcode programmers as there will be REBOL, the speed of that code will make it much appreciated by those who use it.
I look forward to plugins! | Ladislav Mecir
8-Aug-2006 2:38 |
These are the reasons why I support Rebcode:
-it is a great dialect example showing the power of Rebol to the users
-it is great for teaching purposes
-there already exists some code (although a bit "experimental") using Rebcode functions
-even the users not planning to program in Rebcode appreciate its features and will be glad to have it available | Darkblue
8-Aug-2006 3:58 |
:)
I'm supporting Rebcode too, even if the most part of rebolers won't use them, it can be very useful for other ones!
I've been waitng for an official release of rebol including rebcode since I started to use it | Henrik
8-Aug-2006 4:12 |
Do I need to repeat what's been said 3 times already? :) Rebcode fills a large performance gap and it's badly needed. I need it. | Petr Krenzelok
8-Aug-2006 6:40 |
I think that Carl's question about rebcode was more of an academic one. I think that rebcode proved not only being an usefull concept, but also how community can get involved. It appeared suddenly, and was imo very well accepted, and even so - developers nicely contributed to its development on dedicated AltME group.
How can ppl even think about not including rebcode? We don't have compiler, as at least rebcode could speed-up rebol in some specific areas for those who NEED it.
As in regard to past plug-in effort - I am not sure developers were not interested. The thing was, that only IE was planned to be supported, and it was kind of show stopper for many. But it does not matter imo nowadays and surely all developers welcome renewed plug-in support.
As for interest or not generally, I think that RT has to judge according to trends. E.g. according to past developers request for PDA (nearly none), it could be said, that PDA/mobile version of REBOL is not important, but we surely all know, that portability of REBOL to mobile (and other) devices, might be VERY importand in near future ....
Carl writes he long time evaluates where Internet evolves, and I hope mobile devices are part of such a future ...
Cheers,
-pekr- | Gregg Irwin
8-Aug-2006 11:36 |
:)
Yes to Rebcode! Of course, if it added 100K to the kernel, that would be a tough call; but I think the size was minimal; it shows off the power of REBOL and dialects; and provides a way to optimize small bits of code very effectively. Add the bit ops if nothing else. :) | Steeve A
8-Aug-2006 20:40 |
Yes, rebcode is essential. Many applications are impossible to currently consider with Rebol, because it is too slow.
- video streaming
- various image processing algos
- Math calculations on large series
- old arcade games emulator (why not)
Rebol can do that with little effort, we just need SPEED. | MikeL
9-Aug-2006 8:16 |
Methinks the priorities are:
#1 the stable standard browser plug-in that works in more than IE. This would showcase ease of use and portability of REBOL/View
#2 Fixing some of the widgets in View so that they work more like the same widgets in the browser e.g. no more focus problems, .... this gives ease of use and acceptance to View in the plug-in
#3 NTLM support so that REBOL can participate fully in a Windows domain world. We can not have a browser plugin where the logged on user is not recognized ... or the plug-in won't be used in an enterprise.
#4 Interoperability with webservices
#5 Interoperability with message queues ... IBM MQSeries and Microsoft Message Queue | javv
9-Aug-2006 16:16 |
someone in RT should have thought about making web browser plug-ins years ago. flash sorta made it, Java nearly did and still evolving, if only REBOL was there (sigh...), the possibility is endless. | Maxim Olivier-Adlhoch
16-Aug-2006 12:32 |
one thing that many do not consider about rebocode, is that although only a handfull might develop using it...
there is a definite possibility that many will USE that code. if you tell me that you have a 10 time faster execution for some list handling or block navigation algorithm... well, obviously, I'll be the first to want to include that in my list of power tools. Especially if I'm doing a server type app.
so the number of coder vs the number of USERS of rebcode should be considered too in its priority.
As an example of this, many use VID even though they understand none of Face. A few of us do "miracles" using face and draw directly... but so much more use these "miracles" daily. |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
