Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[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" > <snip> > > When I'm working on something, I want all the pieces exposed and layed > out > > in front of me. > > > > When I give it to my customer, I want it in one package. > <snip> > 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, > incremental > 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 > case. > 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