Comments on: REBOL 3.0 Components Design Document Released
We just released a new document that covers the high level design for 3.0 environments, components and plugins. It also introduces our hybrid-open-source approach to this.
REBOL 3.0 Component Architecture
Feel free to post comments to the document here.
11 Comments Comments:
Henrik
20-Jan-2007 1:00:45 |
Is the scheme with /Pro and free version remaining? If so, have you planned which features should be /Pro only?
To me, it seems as if RT can only implement /Pro stuff within the closed, runtime core of R3. Having open source components will give R3 a lot of power and current /Pro features, like strong encryption or ODBC access, could therefore be implemented for free by a third party developer. People would potentially avoid having to pay for /Pro features. | Carl Sassenrath
20-Jan-2007 14:08:33 |
I've thought a lot about that. It is a good question.
The answer comes from analyzing our past experience. The pro/command features have produced only a small income for us. The main reason is that companies want solutions, not just technology or components. Companies want you to "build it for them" not just "give them the tools".
For example, you mention ODBC (database contectivity). We don't want to be the experts in ODBC (we want to be the experts in REBOL). However, we may use a third party REBOL ODBC component to implement a solution for a customer... very much in the same way that you could do the same.
I see the future of our RT business more in partnerships, consulting, special licenses, and packaged solutions. | Goldevil
20-Jan-2007 18:23:06 |
I thinked about the same subject when reading the document.
Where are situated /pro and /command ?
I supposed, that the core & view features will be still 100% free but some /pro and /command features will be proposed as commercial components. Maybe a more modular product line : these components could be bought separately. Then a customer can buy ODBC driver without Fast-CGI or encryption.
Yes, RT will have to compete with other competitors and open source projects. But some components already exists (the ODBC driver is working very well, isn't it).
3 questions : what components
- will be proposed with rebol for free ?
- will be proposed as commercial products ?
- will not be proposed by RT ?
Note : I propose to set a hyperlink "REBOL 3.0 Component Architecture" in the rebol.net homepage (as RT priorities for 2007).
| Carl Sassenrath
21-Jan-2007 0:09:57 |
You said: I supposed, that the core & view features will be still 100% free but some /pro and /command features will be proposed as commercial components.
No... many of the /pro and /command components will be free too, depending. For example, MySQL will be free.
A few very special components will be commercial, not only from RT, but also from developers (who are trying to make money too). There may also be embedded or special environments that are commercial (e.g. Nokia cell phones).
| -pekr-
22-Jan-2007 4:24:20 |
Maybe we could choose only one name? Component or plug-in? If I understand it correctly, components and plug-ins have te same interface? The only difference is, that "component" is name for the "plug-in", which comes directly packed-in executable? Or is there different API?
Thanks,
Petr | Maxim Olivier-Adlhoch
22-Jan-2007 19:29:07 |
Pekr, AFAICT, components are statically linked within the application (or .dll) and plug-ins are dynamically linked once application is initialised and running...
although the end goal might look similar, I think there is a fundamental difference in packaging and why or what you use REBOL for.
Its easier to use dll for an end-user/tinkerer, but its cleaner to relase single file executables for more professional/seasoned developpers.
the plugin could be free, the component could be licensed. | -pekr-
23-Jan-2007 1:16:07 |
Maxim,
I am not sure you are right in all aspects of your post. IMO it has nothing with licensing. Even component could be free.
Yes, components are statically licensed, but imo even today, they are internally "separated". My question was simple - if they do use the same API internally, and the only difference is their "packaging" (e.g. with SDK you eventually can decide, what plug-in you make statically linked, hence becoming a component), then we can all call just components ...
Well, anyway ... that was just my theoretical suggestion, and imo not so important, so, nothing to think about deeply :-) | ScottT
2-Feb-2007 0:29:12 |
This is a finely crafted document that I could not have expected to be more succinct and simple. I am not usually into the marketspeak so heavily, but this seems (from a long-lurking) that this is a significant play, a big step forward that settles many issues and should pave the way to a fine REBOL future.
I hope also that this will mean that RT gets to delegate a lot of refinement for the components that will become open. I also hope there is still that resident hunger to get at the guts of some of it.
I didn't think it could be done, but I think you've successfully imported the best of both worlds with regards to licencing. It won't make some of the open-source camp happy, but you seem to understand where the money is for most of us, and for even some small contracts, RT licencing fees shouldn't be an issue, especially if RT gets to focus foremost on the part that I hope runs on my next cell phone.
| MPM
4-Feb-2007 18:32:03 |
Are you going to update the installation process? On Windows, if you are not an administrator, you can't install. That is as it should be, but if the administrator installs Rebol, as far as a non-admin user is concerned, it still isn't installed.
Compare that to Perl and Python, where installation by an administrator makes the language available for all users. To deploy Rebol-based applications in a business environment will require fixing this.
Far better to use one of the freeware or open source installers out there and get installation right. I know that there are some potential users for the software who are driven away by the current installation process. | Ashley
21-Feb-2007 19:39:12 |
VID should not be an internal component as it represents one of many domain specific uses of View/Draw. In its place should be generic View functions such as those already found in %view-funcs.r and %gfx-funcs.r.
The other internal components are 'building blocks' in that they have little utility in and of themselves, but combined with other components allow powerful higher levels of abstraction.
Lastly, I believe that bundling VID as an internal component has and will deter others from building domain specific abstractions based on View directly (e.g. a forms dialect, a gaming dialect, a reporting dialect, etc).
I'm not suggesting VID be omitted, merely that it be made an optional component present by default (perhaps loaded in %user.r). | Greg Schofield
28-May-2007 5:12:09 |
I am looking again at REBOL with growing interest.
I am unclear about a couple of things, or rather there are couple of things I would like to see.
1) USB portability, having an REBOL application data environment that can be plugged into and used on different OS and and HW platforms. Ideally, something simple like a HTML startup page to boot the right version.
2) Could REBOL 3.0 supply the layout tools for HTML/XML, word processor, DTP, apps and support things like PDF conversion without platform specific binaries? |
Post a Comment:
You can post a comment here. Keep it on-topic.
|
