I complete agree with all suggestions made and have
incorporated them into the prototype, as such. :)
As far as using such a mechanism as a de facto
standard.. well, I say build it and they will come.
Once it's out there with a reasonably large feature
set, then it's going to get picked up, scrutinized,
twisted into pretzels and hacked into something better.
We can't really lose. A standard becomes "whatever
works for the majority".
Maybe we need an anagram for the concept. Kinda like
CPAN, but more oriented towards Rebol components?
=======================================
ERCR (pronouned ERaCeR)
Extensible Rebol Component Repository
=======================================
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.
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.
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
Just a few thoughts :)
--John Schuhr
At 10:30 PM 5/8/2001 -0500, you wrote:
>Hi, John, (and everybody else)
>
>Just a couple of suggestions...
....
>All that said, the larger meta-question remains, "Is this -- or
>something close -- a sufficient mechanism that we could begin to
>use it as a de facto standard within the community?"
>
>If so, can we begin to think about some of the other points,
>such as a conventional tree structure for the units to live in,
>and (harder) do we need a way to keep units from messing with
>the global namespace?
>
>-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.
