UHURU/RSL
[1/10] from: joel::neely::fedex::com at: 25-May-2001 8:07
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 *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*.
> 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.
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[2/10] 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.
<<quoted lines omitted: 19>>
> 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
<<quoted lines omitted: 9>>
> 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:
<<quoted lines omitted: 5>>
> 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
[3/10] from: joel:neely:fedex at: 25-May-2001 21:44
Hello, again, Volker,
I think I'm getting too quickly into too much detail, and
as a result muddying the waters. Let me describe the life
story of a typical UHURU unit. I think we have a high level
of agreement on some key issues.
1) An author has an idea for a useful, general REBOL object
or function. I assume that (s)he is working from enough
experience that the idea is worth sharing and that (s)he
does the homework to develop and test the code before
submitting it.
2) The author builds a single file which contains:
2.1) The meta-data that describes this unit for UHURU,
2.2) Documentation, samples of usage, explanation of
key ideas, or anything else that would help
someone else understand and use this unit,
2.3) The actual working code.
3) The author uploads that file to an UHURU server.
There are some options here, and all of this doesn't have to
be in place on day one, but since I'm imagining... ;-)
4) The UHURU server determines whether this unit is a new
submission, an update to an exising unit, or a duplicate
that it already has (see (6) below).
5) Scripts on the UHURU server read the meta-data and add
appropriate indexing and "what's new" information to
the web site.
6) The server also forwards the unit (single file) to
other UHURU servers with which it coordinates. This
peer-to-peer coordination results in the unit being
offered to all UHURU servers within a reasonably short
time.
Back to the client side...
7) A REBOL user sees that there is a new unit on a topic
of interest to him/her.
8) The user invokes UHURU/install with the fully-qualified
name of the unit.
9) UHURU contacts one of the available servers and retrieves
the unit (single file), using the library path specified
by the user for her/his local box.
10) Install pulls out the documentation (formatting it if
necessary) into a separate .html file, and pulls out the
working code into a separate .r file.
11) Install also determines whether this unit depends on any
other units. It verifies that they are present on the
local box, and will go fetch or update them if needed.
Now that the unit is on his/her local system the user can:
12) Load the unit (with a single UHURU command) into an
interactive REBOL console session to experiment with it.
13) Read the documentation with a standard web browser, and
can cut-and-paste any samples in the docs into a REBOL
console session or into a text editor for experimenting
with the unit.
14) Make a copy of the .r file and experiment with various
changes (it is a good idea to do this on a copy, rather
than the original).
15) Use the unit (in black-box fashion) by adding a single
UHURU command (e.g. UHURU/IMPORT or UHURU/MAKE) into
another script under development. In that case, the
user has the option to simply call on the functionality
of the unit without reading or modifying the code,
exactly as if it had been a built-in mezzanine feature.
Volker Nitsch wrote:
> 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.
>
That wasn't me. My strong preference is one-unit = one-file
as described above.
> I think out difference is with UHURU/install versus
> UHURU/download or UHURU/i-want.
<<quoted lines omitted: 4>>
> But for usage i want it there, knowing everythink about it,
> and not on a lot of servers which may change contents.
The main reasons I see INSTALL being more than a simple
download are that:
- it handles dependencies,
- it automatically "unpacks" code and documentation,
preparing them for effective use,
- it keeps up with what version of what units are present.
But once you've got it, you've got it.
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[4/10] from: john:schuhr at: 25-May-2001 23:03
Joel -- Feel free to distribute the username/password/url for
the UHURU WikiWeb at your discretion. Maybe we can get this
stuff consolidated, organization and stored for posterity.
--John
At 09:44 PM 5/25/2001 -0500, you wrote:
[5/10] from: joel:neely:fedex at: 26-May-2001 9:01
Hi, John,
Thanks! I didn't want to say anything until hearing from you,
since it was your idea and your server.
I've built and used wiki-like tools at work and think it's a
great way to manage information in a distributed project and/or
discussion. I'm just wondering about how the transition from
mail list to wiki can be done most effectively.
I see three options, and I'd like your thoughts on the best
way to proceed:
1) Stay on rebol-list, and just log stuff to the wiki for now.
Pro: We may get input from people who haven't been saying
much up til now.
It will look more like an open, community-level
project.
Con: The mailing list is a poor medium for a permanent
record, especially when bringing someone up to date.
It would take extra effort to duplicate material to
the wiki (although I'd be available to help).
2) Publicize the wiki to the entire list.
Pro: Nobody is excluded, keeping the "community spirit".
Nobody has to do any extra work to keep the list and
the wiki in synch.
Con: Too broad a group too early could lead to possible
loss of focus or difficulty in getting consensus.
Someone who gets really annoyed could mess things up
for everyone else. (I just witnessed an "incident"
on another list I monitor where two guys got into a
flame war that escalated out of control and sucked in
a bunch of other people as well. I think this group
is MUCH more mature, but given that a wiki is totally
open, there is the possibility...)
3) Make the wiki invitation-only. Post summaries to the
mailing list at appropriate points in the discussion.
Pro: More control.
Con: More control.
This could make the effort read much less like a
"community library" and foster more of a "them vs.
us" mentality. The number of possible contributors
is small enough that a split would add real risk.
Is one of these a winner? Are there any other alternatives?
-jn-
John Schuhr wrote:
> Joel -- Feel free to distribute the username/password/url for
> the UHURU WikiWeb at your discretion. Maybe we can get this
> stuff consolidated, organization and stored for posterity.
>
> --John
>
-jn-
------------------------------------------------------------
Programming languages: compact, powerful, simple ...
Pick any two!
joel'dot'neely'at'fedex'dot'com
[6/10] from: gjones05:mail:orion at: 26-May-2001 9:38
From: "Joel Neely"
<snip>
> 1) Stay on rebol-list, and just log stuff to the wiki for now.
<<quoted lines omitted: 3>>
<snip>
> Is one of these a winner?
loop 100 [print random/only ['yes 'no]]
;-)
> Are there any other alternatives?
Is there such a thing as a moderated wiki? Open to all; changes are
dynamic but highlighted initially (like a group-edited word processing
document); and changes are only fully integrated and made permanent
after being signed off by a selected/elected member of the moderator
group. (Side note: what a great group-ware software idea for REBOL.) Am
I "over the top" on this idea?
Has any one ever implemented a wiki distiller? Additions are collected
and refined, and as more and more approval is given, the core nuggets
get distilled into an uber document.
Just thinking out loud again (yes, for careful readers of all the
threads, I *have* been painting already).
--Scott Jones
[7/10] from: john:schuhr at: 28-May-2001 18:04
Sorry for long delay in replying. For the use of everyone
interested in furthering the REBOL-CPAN project (UHURU), I've
set up a wikiweb to help the collaboration. I think the
documentation of the wikiweb should play like this:
1) Post all new ideas, RFC's and questions to the mailing-list.
I may just create a UHURU mailing list, if anyone thinks it
might be handy. This way, everyone can yammer about theoretical
and philosophical points before it's concreted.
2) For agreed upon material, or slight tweaking of existing
material, this will be done on the wikiweb. Also, posting
of explanatory text is welcome on the wikiweb.
3) I'll occasionally pick the meat out of the mailing list
and summarize/organize it on the wikiweb, if it's not already
there.
You can find the wikiweb at:
http://guest:[uhuru--rpgcatalyst--com]/phpwiki
Comments?
--John Schuhr
At 09:01 AM 5/26/2001 -0500, you wrote:
[8/10] from: chris:starforge:demon at: 29-May-2001 11:42
John Schuhr wrote:
> You can find the wikiweb at:
> http://guest:[uhuru--rpgcatalyst--com]/phpwiki
>
> Comments?
This is missing the large summaries I posted on Friday and Saturday. Do
you want me to add them to the wiki?
Chris
[9/10] from: john:schuhr at: 29-May-2001 13:46
Absolutely.. :)
At 11:42 AM 5/29/2001 +0100, you wrote:
[10/10] from: chris:starforge:demon at: 5-Jun-2001 15:05
John Schuhr wrote:
> Sorry for long delay in replying. For the use of everyone
> interested in furthering the REBOL-CPAN project (UHURU), I've
> set up a wikiweb to help the collaboration. I think the
> documentation of the wikiweb should play like this:
My apologies that I haven't uploaded my large summaries to the
wikiweb yet (if someone has done it for me, my thanks..) I have had a
particularly nasty run of flu which kept me not only off work (not
so hard) but away from my computers (very hard) for the best part of
a week. I'll upload the summaries once I've caught up with everything!
:/
Chris
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted