Doesn't we have read-thru?
Why another mechanism?
Then, i find cut&paste often more usefull then wrapping with objects,
since i can hack it to fit my needs.
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.
Something which collects all this snippets with a search-engine
would be nice. Kind of Frequently Needed Code ? :)
Volker
>>>>>>>>>>>>>>>>>> Urspr�ngliche Nachricht <<<<<<<<<<<<<<<<<<
Am 09.05.01, 06:52:50, schrieb John Schuhr <[EMAIL PROTECTED]> zum Thema
[REBOL] Re: Enabling the REBOL community:
> 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.
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
