[REBOL] Re: UHURU/RSL
From: joel::neely::fedex::com at: 25-May-2001 8:07
Let me clarify my perspective on smart-client-dumb-server.
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"
> I think, first we should use rebol.
> 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 *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
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*.
> 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.
Programming languages: compact, powerful, simple ...
Pick any two!