[REBOL] Re: even further ... Re: Introducing REBOL/Base - FAQ
From: petr:krenzelok:trz:cz at: 3-Oct-2002 22:08
Gregg Irwin wrote:
>DLLs aren't the problem of course. People are. :) I *love* reusable
>libraries of code! I couldn't live without them. The question is, how to
>make it work? Because of the way REBOL works, we're probably going to be
>seeing apps that are built of many small pieces which may change
>dynamically. Whether the concept of Web Services takes off or not, the world
>is different now. With REBOL, it's about communication (messaging). We don't
>have to use components and libraries as we have, historically, with other
>langugages. We need a good model that is simple, flexible, and robust. Lots
>of details to consider on that front.
>
yes, and that's what I said - just let's do it right. I also remember
one email from Carl some year or two ago, stating that he knows very
well what the dynamic system should be all about. So I consider current
Rebol state still Rebol 1.0 generation ... we need to move forwards
though ....
>In any case, RT seems to have a plan. They released /Base and Carl said they
>want to know what we think, so let's keep thinking and telling them.
>
we do so ... I always try to see bigger perspective .... /base is step
in a good direction, but not enough revolutionary - it separates only
mezzanine level and RT has yet to show us - how to make it usefull,
especially in combination with their preprocessor ....
> He also
>said another tool would be forthcoming to help with including the pieces
>they took out, so I think they have something in mind about how to handle
>this.
>
yes - preprocessor imo ...
>What do *I* want as a developer?
>
>I want to be able to send out a single EXE, that isn't dependent on anything
>that might be changed for the OS or another app. External pieces I ship
>should not be used by anyone else, so I can handle them however I want. If I
>break my own app, that's my fault.
>
now the options:
1) Encap your app ....
pros: hides source code, allows you to keep everything in one file ...)
cons: it works upon one platform only though, requires you to
redistribute whole executable once you patch the bug or want to
distribute newer version of rebol itself
That model might work for platform specific development - small tools or
apps, or even bigger ones, where bandwidth is no problem ...
2) Rebol player - distribute rebol/base or rebol/view/base and pack
everything using preprocessor into one package. So we've got two files.
Rebol, and platform agnostic rebol app package. You could even create
real player :-) just press "play" button upon selected package and voila
.....
Still does not work well for small dynamic devices. That's why I want
more ... call me a perfectionist ... or am I just pedant? :-)
3) X-Inet apps - not "player" based ...
a) introduce finally async networking. Why should I wait for my app
window to appear, just because I am downloading background image?
b) script or even player package, checking if Sound 1.3 is available. If
not - download new component and plug-it in. Forget of rebol.exe being
everything. It can't work if you want rebol to play mp3s, avis, do 3D
graphics, strong math, etc. in the future.
That's kind of model I would like to see introduced in two years horizon
... PDAs and other mobile stuff will become even more widespread, Rebol
will get more functionality, but bandwidth will not still be cheap
enough to waste it by downloading new rebol.exe, just because of upgrade
of one of its components ....
>If I deploy a script, either it's targeted at REBOL developers, sysadmins,
>etc. who know how this stuff works, or it's for users. If it's for users,
>there needs to be a single interpreter/runtime that is used for everything
>(IMHO). E.g. under Windows, .r files will be associated with rebol.exe and
>that version of rebol needs to be able to run every script they might get.
>This doesn't fit very well with the current model though.
>
And that's exactly what I am talking about - we need one and only one
rebol.exe kernel - everything other is component ....
>Keep brainstorming!
>
good comments anyway! :-)
-pekr-
