Comments below :) ---------- > From: Joel Neely <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [REBOL] Re: Enabling the REBOL community > Date: Wed, 09 May 2001 07:42:41 -0500 > > Hi, John, > > John Schuhr wrote: > > > .... > > > > Maybe we need an anagram for the concept. Kinda like > > CPAN, but more oriented towards Rebol components? > > > > ======================================= > > ERCR (pronouned ERaCeR) > > Extensible Rebol Component Repository > > ======================================= > > > > How about acronyming into Swahili, and calling it UHURU > (which means "freedom", an appropriate meaning for a tool > to unchain the power of REBOL). > > Universal Home for Useful Rebol Units Sounds good to me :) Anything catchy is good. > > > > > Another possibility had popped in my head briefly of > > rigging the Component Manager (working term) to update > > modules from a central location (hence the Repository > > part of ERCR) on demand. Kinda like: > > > > unit/update-lib %ERCR/libraries/text/textproc/parsers > > ;or using the working term "Rebol Component Manager" > > rcm/update-lib %ERCR/libraries/text/textproc/parsers > > > > This would cause the CM (Component Manager) to hit > > against the ERCR and look for new versions of the > > "ERCR/libraries/text/textproc/parsers" library, > > based on version numbers in the REBOL headers or > > some such thing. > > > > Sure. Add to that the idea of updating an entire branch > of the unit library (for those with the bandwidth and > time ;-) similar to > > unit/update-all %text/textproc/ > ;or, using the alternate acronym ;-) > UHURU/update-all %text/textproc/ > > which would recursively add all units AND branches (aka > directories) under that prefix. Well, I was thinking that a unit library would only be located at the bottom of the hierarchy. Which is to say the %text/textproc path isn't actually a library, but contains several libraries. So if one were to specify a non-library path, then the Unit Manager would assume you mean to update all contained libraries recursively. But you may have the right of it by using a seperate function to eliminate any ambiguity. > > Incidentally, I also assume that the "ERCR/libraries" > (or "/usr/local/bin/rebol-lib/UHURU/" or whatever) would > be supplied automatically, based on whatever library > path(s) had been set up for the specific box. I think the UHUHRU part of the path should be part of all units paths. So the cdf-parser would be called: UHURU/libraries/text/textproc/parsers/cdf.r And it would be up to the user as to where the UHURU home resides on their box. So they could have it in /usr/local/rebol/lib making the overall path into /usr/local/rebol/lib/UHURU... and they would use the following in their rebol.r: unit/add-lib-path %/usr/local/rebol/lib But unless the unit manager does recursive path searching you would have to specify: my-cdf-parse: unit/new UHURU/libraries/text/textproc/parsers/cdf Ick. Thoughts? > > This raises an interesting issue: suppose one had the > following code in user.r or rebol.r > > > do %/usr/local/bin/rebol-lib/unit.r > unit/add-lib-path %/usr/local/bin/rebol-lib > unit/add-lib-path %/home/myacct/rebol-dev/lib > > There are now several policy options for what it means to > say > > unit/update-all %text/textproc/ > > with multiple paths set up: > > 1) Assume that the first path in lib-paths is the public > library, and add everything there. > 2) Search all paths until finding one that contains a > subpath of "text/textproc/" and add everthing there. > 3) Search all paths, finding EACH one that contains a > subpath of "text/textproc/" and add to all such. > 4) Ask the user which path(s) to add into. > > If no such sub-path could be found anywhere, either > > 5) Fail the update attempt, with appropriate notification. > 6) Assume that the first path in lib-paths is the public > library, and add everything there. > 7) Ask the user which path(s) to add into. > > I don't like (4) and (7), as they interfere with the ability > to run a cron job in the middle of the night to update my > libraries. > > Perhaps the best policy is "no policy -- specify which you > want with a refinement" with some defaults, such as (1) and > (6). I agree with the "no default policy but feel free to create your own with the given feature set" approach :) > > > Naturally, all components submitted for inclusion into > > the ERCR would need to meet certain specifications for > > providing documentation, standard interfaces and respecting > > namespaces. Perhaps each component could be _forced_ > > to use a local context. > > > > How? Good question. It's wishful thinking. > > One of the nice features of Perl's "use <module>" mechanism > is that one can explicitly indicate which names from the > module should be exported into the current namespace. > For example (using hypothetical REBOL syntax), it would be > nice to define a unit as > > unit [simpson montecarlo] [ > hiddenfunc1 func ... ;; details omitted > ... > hiddenfuncN func ... ;; details omitted > simpson: func ... ;; details omitted > montecarlo: func ... ;; details omitted > ] > > then utilize it via > > math-stuff: unit/new %math/integration > ... > math-stuff/simpson ... > math-stuff/montecarlo ... > > or via > > math-stuff: unit/new/import %math/integration [ > simpson montecarlo > ] > ... > simpson ... > montecarlo ... > > but strictly WITHIN the current namespace. We may have to rely on RT for some mechanism in that regard. Unless someone out there knows a nifty hack for just such a thing. > > > > > As for a categorical tree for components, all I can > > suggest is that we get started and go from there :) > > > > For example: > > ERCR/libraries/network/protocol/ertp.r > > ERCR/libraries/text/string/similarity.r > > ERCR/libraries/text/string/shellquote.r > > ERCR/libraries/text/textproc/parsers/cdf.r > > ERCR/libraries/text/textproc/algorithms/soundex.r > > ERCR/libraries/text/textproc/generators/pdf.r > > > > I agree with the above, provided we can suppress the > > ERCR/libraries > > prefix, and leave it up to each platform/box to configure > individually where in its directory structure the library > tree is rooted. > > -jn- > -- > To unsubscribe from this list, please send an email to > [EMAIL PROTECTED] with "unsubscribe" in the > subject, without the quotes. > -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
