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


From: agem:crosswinds at: 25-May-2001 22:37

>>>>>>>>>>>>>>>>>> Ursprüngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 25.05.01, 14:07:33, schrieb Joel Neely <[joel--neely--fedex--com]> zum Thema [REBOL] Re: UHURU/RSL:
> Hi, Volker, > Let me clarify my perspective on smart-client-dumb-server. > -jn- > Volker Nitsch wrote: > > > > Thread sound a lot to conventional to me. > > > Speaking for myself, I interested in having (and helping to > create) an effective, scalable, portable library. If it meets > those criteria, I'm indifferent to whether it is "conventional" > or not. > > > > I think, first we should use rebol. > > > Agreed. > > So why this smart-server-stuff? > Again, speaking for myself, I haven't asked for any "smart > server stuff", nor do I think it's particularly useful. I > *do* want multiple servers with identical images of the > library's content, both for fault-tolerance and optionally > to allow the client-side user the choice of which server(s) > to prefer (for whatever reason), but I haven't proposed any > server-side capabilities beyond httpd.
I was a bit lost in thread :) somewhere is talking about scripts with extensive/medium/no documentation, and if we store stripped scripts to, increasing space and so on. I think we could store scripts in multiple parts on the server together with a merger-script, and for download do this merger-script, which generates a customized version in one file. hm. that would be a point to a standarized form with script and docu-file and so on?
> I *have* considered (although I haven't proposed it on this > list before now) the idea that if UHURU units have a standard > format (whether the one I imagined or some other scheme), the > server *could* maintain some additional niceties, such as: > 1) a keyword-based search engine returning the paths, names, > and descriptive blurbs for all library units matching a > visitor-supplied set of search terms, > 2) a site-map-like diagram or outline showing the entire > concept hierarchy, > 3) a "what's new" list of recently-submitted units, > 4) and other similar packaging. > However, none of these go beyond the kind of thing that *ANY* > well-maintained web site has, *regardless of content type*.
Yes yes yes yes :)
> > > > Carl shows us allways: > > put some files on the server, download a maker-script, > > do it, voila, there is what you want. > > Let the client do the work :) > > > This is almost exactly what I described. UHURU/install *was* > described as client-side, and would (as stated above) need > nothing more than httpd on the server.
I think out difference is with UHURU/install versus UHURU/download or UHURU/i-want. I like to need two things: my rebol and my scripts dir. What i place there while developing i would like to get with much comfort :) But for usage i want it there, knowing everythink about it, and not on a lot of servers which may change contents. Stability and calculability counts for me more than having all newest features automatic. Its reaction time online/on-tel, i don't like to say »hm, sorry, my computer somehow.. ten minutes please..«
> -jn-