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 >>> >>><[EMAIL PROTECTED]> wrote: >>> >>> >>>>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 >real windows-user). > >The MS-way of providing 501k-applications to download? What do you smoking? ;) > > :-)) LSD - Liquid Steel Dialect?
>5.01M maybe. >Thinking again, where did you find 501k-scripts? 50,1k-scripts are more >realistic. > > Well, that is missunderstanding. I thought that Robert is suggesting encapping our apps, which imo leads to redundancy. I also heard "official places" 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 >malfunctions? > 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 anybody ... -pekr- > > >>-pekr- >> >> > >-Volker > > > -- To unsubscribe from this list, just send an email to [EMAIL PROTECTED] with unsubscribe as the subject.
