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