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


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