[REBOL] Re: Commercializing Rebol
From: agem:crosswinds at: 16-May-2001 21:45
>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 16.05.01, 16:15:35, schrieb "GS Jones" <[gjones05--mail--orion--org]> zum
Thema [REBOL] Re: Commercializing Rebol:
> From: "Ken Anthony"
> > When I'm working on something, I want all the pieces exposed and layed
> > in front of me.
> > When I give it to my customer, I want it in one package.
> And this is precisely how the TclKit-MetaKit combination works. Your
> development files are laid out as you like them, but the TclKit
> scripting document creator program combines them into a single,
> executable file. The components are reached through the database
> system. The end user only sees and deals with the one file in a
> scenario (as always, there is a little more to the story...). It is
> the concept on which I am focusing, and the concept seems very neat.
> also seems "doable" in REBOL, at least in principle. Problems remain;
> this solution is hardly a panacea.
Its mostly easy with rebol.
I played with a filesystem + content in a scripts, which is available
thru a scheme (ram://).
I can switch the scheme, so on development it simply accesses hd
and on distibution it accesses the ram-cache.
Some problems because some stuff can only be done with files, not urls
('change-dir and with it 'system/script/header/file)
but mostly one can have a whole filesystem in a script.
Since its a scheme, one can easy copy from hd to ram:// and back ,
or making a scheme ram2:// from it..
> KA> I will worry about size and how to update. While in principle,
> KA> updates are a neat idea, in practice it just leads to job security
> in the
> KA> support department.
> Oh, so true. Just supporting my wife's cobbled together eBay and
> website management scripts is more work than I care for it to be, but
> believe that a scripted document-type approach would be easier in our
> As an aside, one might ask why not just use Tcl/Tk and the
> aforementioned package. I was going to, but I have this mental block
> the Tk model for a gui. I just never got up to speed in Tk, certainly
> in comparison to /View VID.
> This single, "scripted document" arrangement is a very compelling
> concept to me, putting aside, for the moment, Petr K's well founded
> easily understood concerns. I have additional and, as yet,
> concerns and reservations. One is the idea that any data is ever
> encoded in a non-directly readable format. Legacy problems become
> built-in, and this seems to be a bad design choice make from the very
> outset! I take some consolation that the solution mentioned is open
> source, and that the binary is cross-platform compatible without need
> for translation of endians, etc. I guess I always want my cake and to
> eat it too. I want the information to be stored in a human-readable
> format and yet quickly addressable and compressed!
> --Scott Jones