[REBOL] Re: CPAN for REBOL
From: bobr:dprc at: 4-Mar-2001 0:01
At 05:31 AM 3/3/01 -0500, Mark Dickson wrote:
>The Script Library at REBOL.com is only updated infrequently
>and REBOL.org appears all but dead.
if you have an update that is overdue, bring it to my attention.
there is a subgroup of us revising the
rebol.org site to add more interactivity, etc.
we are not looking for enhancement requests
but we can accelerate true submissions of code.
>I would like to enquire if anybody has the time to setup and run
>effectively a Comprehensive Archive Network simlir to PERL CPAN
>for REBOL scripts.
I have been working at this for the last year.
"code only when you -have- to"
Ideally, to quickly evolve a CPAN ( CrAN? CARLs? )
one would like to build on the work of others.
It should be trivial (and I don't mean get the source and fork a new
version) to build on someone else's work and discoveries and include
that work as a foundation to your own.
As well, it probably needs to be automatic to
include the most recent version of some
other authors code within your own creations without having
to edit your mods in again.
REBOL's built in capability to 'DO a URL goes a long way toward this.
At the same time, it should be easy to
make standalone files or files with live
built-in test cases and sample values. (an unadorned 'do runs the examples)
Working with the "N" (network) part of CPAN I realize that unlike java,
rebol does not require all things come from the same source or domain.
The author is free to trust any source they wish for 'do-ing sub-modules.
I see a more distributed system is possible. I would like to assist in
spreading out the central-depository approach and leave the maintainer free
to make updates continuously. It would be nicer if you went right to the
source (maintainer) for certain modules or foundation code.
In that case rebol.org may just evolve to be
a directory of resources and module start points.
The current problem is that there is very little discipline used on this list
that would create truly modular layers or do-callable sub-modules.
We get plenty of great examples with plenty of hardcoded sample values.
Not much that can stand on its own yet give remote invokers the ability to
refine the hard-coded values beforehand without altering the authors
intended utility. I hope to change that. The work I have
been do-ing (pun) tries to showcase what is possible through
modular layering.
" But isn't 'do-ing over the net slow? "
It could be -- that is where caching can help.
That's where YOU (reader) can help.
This caching issue came up when I got
involved with reb-world game development.
Consider:
do http://www.mysite.com/reboltools/hammer.r
this would load hammer.r every time across the net.
What if there were an object! or function:
cache/do http://www.mysite.com/~bobr/reboltools/hammer.r
that would check against a local version and do that one first
and only check the net for something newer, say once a week?
The function would have to be able to distinguish hammer.r
as different from ~jeff/somesubdir/hammer.r without requiring
lots of subdirs on the local machine. Perhaps a hash of the path is used.
Controlling your cache 101
We have to be able to set bounds and timing ... I propose a setup function
with appropriate refinements:
cache/setup/size 10240000 ; nearly 10 megs
cache/setup/recheck-every 24:0:0 ; once a day, default is once a week
An additional requirement would be that the owner of the cache be allowed
to set which dirs were used to store which domains/subpaths
cache/setup/location-for "jeff/somesubd"
%tmp/bargain-basement-scripts/jeff/
so that if the owner of the local machine pleased, they could remove all
the files in a certain directory and only affect a specific (knowable)
portion of the cache.
cache/setup/save %tmp/netcache.r
would save the current operating parameters (if any) out to disk.
cache/setup/install %user.r
would update user.r so the cache is loaded on every callup of rebol.
cache/setup/improve-system-do
would replace the 'do function so that all calls to 'do check the cache
first if the argument is a URL and invoke the system one otherwise. This
way no coding change is required for older scripts to begin working with
the new caching.
For other common operations:
cache/clearall
cache/setup/trace true
cache/setup/offline true ; disable weekly recheck till back online
Finally, this has to work in /core with cgi's
cause that's where you get some of the most
steep penalties for going
back out over the net.
With that spec in mind I am looking for writers.
Of course the cache will itself be loaded as 'do able code!
I promise great fame to the writer. If you don't have your own
website to host docache.r (or whatever you choose to call it)
I can find some hosting for you - very quick.
>A properly managed resource system for REBOL scripts and examples
>is invaluable for REBOL's credibility as a language. Lots of great script
>examples are posted on this list, but is anybody making a coherent and
>useful resource with them?
ME. I have a fine list of "keepers".
My plan is to make it possible to have others contribute and refine the
keepers pile on rebol.org
>If anybody want's to discuss a CPAN for REBOL please raise your voice
>here!
BUT NO SHOUTING (please ;)
>PS I've also thought of a cute name that might please a certain gentleman
>at REBOL TEchnologies Inc.
>
>Here's the name, it's an acronym, of course!
>
>CARLS: Comprehensive Archive REBOL Language Scripts
Isn't that the name of a west coast fast-food chain?
Well, at least it leads to something edible! <smile>
