[REBOL] Re: UHURU/RSL
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-
Volker
