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

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