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

[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-