Mailing List Archive: Re: Enabling the REBOL community

[REBOL] Re: Enabling the REBOL community

From: joel:neely:fedex at: 9-May-2001 7:42


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

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

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.

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).

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

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.

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