[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: languages

This page is part of the web mail archives of SRFI 83 from before July 7th, 2015. The new archives for SRFI 83 contain all messages, not just those from before July 7th, 2015.



 | Date: Tue, 14 Mar 2006 14:58:28 -0800 (PST)
 | From: bear <bear@xxxxxxxxx>
 | 
 | On Tue, 14 Mar 2006, Chris Hanson wrote:
 | 
 | >bear wrote:
 | >>
 | >> So to me a scheme URI would be something like
 | >>
 | >> "scheme://R5RS/TinyCLOS/rationals/foo.scm"
 | >>
 | >> and this woud be a key into a small database that mapped
 | >> it to a URL giving a web address where it could be downloaded.
 | 
 | >But why not just use an http: URI to do that?  You don't need the
 | >small database at all.  Something like
 | >
 | >	http://schemers.org/R5RS/TinyCLOS/rationals/foo.scm
 | 
 | I think that would imply excessive reliance on a single
 | site and server. And this is sometimes a problem.  Aside
 | from the situation becoming such that the entire community
 | would be hosed if a single server should go down, it would
 | impose a significant burden (and bandwidth costs) on the
 | maintainers of that site.

I believe Chris is suggesting multiple sites:

      http://swissnet.ai.mit.edu/~jaffer/slib/
      http://www.call-with-current-continuation.org/eggs/
      http://sourceforge.net/projects/awg-scheme-libs/
      http://www.plt-scheme.org/software/
      http://www-spi.lip6.fr/~queinnec/WWW/Meroon.html
      http://planet.plt-scheme.org/
      http://sourceforge.net/projects/schematics/
      http://schemecookbook.org/Cookbook/LibraryIndex
      http://www.neilvandyke.org/
      http://www.barzilay.org/Swindle/

A less idiosyncratic site for SLIB could be
http://savannah.gnu.org/projects/slib/ or
http://ftp.gnu.org/gnu/slib/.

 | > The database could be stored on the server instead of having a
 | > local copy everywhere.

SLIB maintains a local catalog (database) of named modules on the host
running or compiling Scheme.  "(require 'new-catalog)" rebuilds the
catalog; which is also done if the catalog is missing.  This approach
works well and runs quickly.

Going out to the web for every module request is a bad idea.  Programs
which worked yesterday may fail today if a module has been changed.  A
program will fail to run if a server hosting a module it needs is
inaccessible.

A library of interest should be downloaded and stored on the local
host, its entries integrated into the catalog on the local machine.
These operations can of course be automated.