[REBOL] Re: DLL Hell = Rebol library script version
From: petr:krenzelok:trz:cz at: 12-Nov-2003 9:16
Volker Nitsch wrote:
>Am Dienstag, 11. November 2003 19:57 schrieb Petr Krenzelok:
>>Robert M. Münch wrote:
>>>On Tue, 11 Nov 2003 09:28:36 +1300, Andrew Martin
>>>>When distributing a Rebol script,
>>>>include all the functions (words) that the main script requires. Of
>>>>course, the problem here is that most of us have nice toolkits of
>>>>functions that we want to use in our main script applications, and it's
>>>>pointless manually copying and pasting from our toolkit because that
>>>>just produces multiple copies, with no definitive, authoritive source.
>>>Hi, IMO that's they way to go: Include all stuff in one script. As long as
>>>this particular script works, there is no need to update the included
>>>part. How to do it? Well, include PREBOL in the core engine. I don't know
>>>why this isn't done. Replace the #... PREBOL commands thru something like
>>>$... and have the interpreter recognize this.
>>I just hope I don't understand you correctly robert, but aren't you
>>suggesting having rebol distributed with all of our scripts? That is MS
>>way of doing things, waste of bandwidth etc. There should be central
>>engine - rebol/whatever installed on your hd, it should check for its
>>updates and scripts should come as packages (as IOS desktop does). I
>>would hate to redownload 500KB each time just because someone changes
>>one function in script ...
>The MS-way of providing everything and keep it out of the system works very
>well. unfortunally its not the MS-way, some stuff is always placed in
>system-dirs. Overwriting another version. (hmm, is this true today? not a
>The MS-way of providing 501k-applications to download? What do you smoking? ;)
:-)) LSD - Liquid Steel Dialect?
>Thinking again, where did you find 501k-scripts? 50,1k-scripts are more
Well, that is missunderstanding. I thought that Robert is suggesting
encapping our apps, which imo leads to redundancy. I also heard
stating, that it is not too much - but hey, who
started Rebol just because of being more efficient? What about mobile
devices? So you encap your app and you let your users redownload it each
time just because you change one color of a button? :-) I think that -
1) Rebol should become engine - sitting on our HDs, being able to update
itself eventually - kind of JVM. Then you could just distribute your scripts
2) You distribute your app, but rebol is separate and your app is kind
of compressed package, so you can redownload only your app.
Both points save you from redundancy, wasted bandwidth. If your tool
will be downloaded by 10K ppl, you will sing different song, if you are
supposed to 10K * 50x app, or 10K * x package
>Rebol enables us to provide apps this size. Why should we introduce risc of
When speaking of malfunction, I can tell you following - current
situation is just that - malfunction. View should imo take different
aproach - register/install into registry only when forced to. So, what
is your .r registered to? Base? Face? Core? Command? View? Which one?
1.2.1? 1.2.8? 1.2.10? Command? View/Command? Eh? I hope that if R# sees
the light of the day, there is the promise of ONE single executable kernel, and the rest
being modules. I remember Carl stating that he is
father of modular amiga system, but rebol is not modular, componentised
yet. And I also remember someone stating, that current state (product
diferentiation) is so because of marketing reasons. So - don't you hate
when marketing stands in the way of technology? ;-)
> If it does not work, user spends a lot more time fixing a
>problem then downloading everything.
You know better than me that it can be solved by semi-intelligent
system. Amiga works that way, libraries have their version number - what
is the problem? So you better like compromises like uncomplete sound
system, no support for mp3 etc., because it would make View big? Well -
that is way to nowhere. If sound component would be separate binary,
library, module, component, call it whatever - you would not mind it
having e.g. 200 kb, but with current state it would simply make View too
big for some ppl to like it.
>Regarding IOS, all scripts work standalone, there is no script which does
>another. And that would be very simple with ios-distribution.
IOS is different. And while it is nice architecture, its main drawback
is just that - all scripts work standalone and I hope competent ppl do
something about it to take IOS further. Complete isolation does not help