[REBOL] Re: Enabling the REBOL community
From: joel:neely:fedex at: 9-May-2001 8:15
Hi, Volker,
Fair questions, but experience with such mechanisms in other
communities can suggest some answers. A comprehensive
unit management scheme (I think I'll stick with calling it
UHURU until we can take a community vote/poll) addresses
a number of software engineering issues and community
development issues, both of which I think would benefit
REBOL. (And I know that we all agree on THAT goal!)
Volker Nitsch wrote:
> Doesn't we have read-thru?
> Why another mechanism?
>
READ-THRU might very well be *part* of the mechanism, but it
isn't a complete answer to the fundamental issues being raised.
* You still have to have a source URL. What if you don't know
which of several dozen uncoordinated volunteer sites has the
unit you need? UHURU should support multiple mirror sites
with the identical "community standard" content. When I go
to get a unit, I should be able to tell UHURU to get me a
unit by its community standard designation, and let UHURU
deal with switching mirrors due to downed servers, etc.
* The whole business of "community standard designation" is
a BIG DEAL when the volume of available content begins to
scale up. The REBOL/View desktop currently shows 28
"Reb sites". In addition, I think there are about another
dozen web sites not directly exposed as "Reb sites". If I
know that somebody implemented a nice block-to-xml output
function, I now have to keep up with (or search through)
about three dozen places it might be. What will I do when
there are a few hundred active contributors of REBOL code?
(Or, more realistically, will there EVER be a few hundred
as long as we don't have an effective publishing system?)
OTOH, if somebody writes that nice block-to-xml output
function and submits it to UHURU under the path
/xml
or
/xml/unparse
(or whatever the community establishes), then I can find it.
This subject-based (instead of contributor-based) structure
also lets me effectively (i.e., by concept) search the UHURU
library tree for new submissions that might be useful to me.
> Then, i find cut&paste often more usefull then wrapping with objects,
> since i can hack it to fit my needs.
>
You're certainly entitled to practice reuse by cut-and-paste if
it works for you (and nothing in my proposals would prevent that
practice), but it is totally unsatisfactory for my needs. One
simple example suffices for my concern.
I've written a unit that implements some generic traversal and
processing functions over the block structures produced by the
built-in XML parser. I've used that unit in many specific
applications. A while back, I thought of a way to enhance the
performance of one of its methods.
Since the unit was maintained in a separate source file and
include
-ed where needed, I was able to implement the improvement
in that one file. Every other piece of code that used it got
the benefit the next time it was executed. If I had been using
cut-and-paste, the amount of labor required to make (universally)
that improvement would have been arbitrarily larger. I don't
have time to go around and manually re-tweak N+1 copies of the
same source, pasted into N+1 different places.
> Means, if i have a sceleton for a subdir-search i can
> change it to report the files i want, with/without dirs and so on.
> That flexibility pre-coded would need a lot of inbuild options.
>
I'm not sure I understand. If we separate out the list of
paths from the core UHURU code, then let you configure it on
your own system to search a specified list of paths in a specified
order, that gives you the flexibility without having to explicitly
set options all over the place. Or did I misunderstand your point?
-jn-
