Am Mi., 26. Okt. 2022 um 18:11 Uhr schrieb Marc Feeley - feeley at
iro.umontreal.ca (via srfi-discuss list)
<xxxxxx@srfi.schemers.org>:
>
>
> > On Oct 26, 2022, at 11:29 AM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
> >
> > One reason why it is actually not a good idea to have library names
> > like (github.com/gambit/examples hello) just occurred to me:
> >
> > If, at some point, an author decides to move their repositories from,
> > say, GitHub to GitLab or Codeberg, or Savannah (which can be due to
> > political reasons or because some repository provider ceases to
> > exist), the names of this author's libraries would no longer reflect
> > where they can be found.  While this would not harm the functionality
> > of the libraries, it would confuse users (who like to click on the
> > auto-formatted links in their editors) and loaders that pull source
> > code directly from the internet.  Of course, the libraries could be
> > renamed, but this should only become necessary if a new version of the
> > library becomes gravely incompatible with the previous version.
> >
> > Making a library name dependent on a location thus clashes with its
> > primary use of giving a (universal) name to a particular library.  In
> > other words, it makes sense to base a library name on a URN, but not
> > on a URI.
> >
> > A URN-like scheme (the SRFI process is one) at least solves the
> > problem with namespacing.  What's missing is a connection between URN
> > and URI, which should not be part of the library definition by the
> > above reasoning.  It belongs to some metadata outside of the library;
> > this necessary metadata can also contain some solutions for security
> > issues.
>
> With URNs we are back with the problem of a centralized system. Some organization has to assign names and “bless” the libraries as conforming to the standards it has. It also makes installing libraries a necessary step and harder when you want some library that isn’t blessed.

It's not true (at least not without extra assumptions) that URNs mean
a centralized system.  For example, there are (version-4) UUID urns to
give a trivial example.

A probably more practical way is to use a scheme based on what is in
SRFI 97: A central authority (the "Counter") gives out a number on
request (without any judging or blessing).  The corresponding library
names will then be like

(package 3 awesome-hashtable)
(package 494 example fireworks)
(package 495 example fireworks)
(package 1292 gambit compiler optimizer)

where "package" is a dummy name to be agreed upon.  Here, the two
fireworks libraries would be completely independent.  I wrote "central
authority," but this is no worse than GitHub or the DNS.

If one doesn't want to use the "package" authority, they can still
invent their own schemes.  It won't be compulsory.

> A situation that concerns me is the period of time when a library is being developed and not yet ready to be published on the centralized system.  I view libraries as organisms that evolve over time rather than pristine things that will never change (I view SRFIs as the latter, and not the “usual case” for a library). What if you want other developers to try out your “WIP library” and maybe collaborate with its development? You would need a separate installation process for this case, which is just an added barrier to collaboration.

Assigning a URN (as per the above central counter, for example) is not
the same as publishing on a centralized system.

> The solution to the problem you mention is to allow a configurable mapping of library names. This is what the Gambit define-module-alias does:
>
> (define module-alias (github.com/old-account/old-lib-name) (gitlab.com/new-account/new-lib-name))
>
> So the URI in the library name is fundamentally just a way to identify the library unambiguously. In the great majority of cases the URI also points to the repository where the library source code can be found. [Fun fact: if you move a github repository to a new account and/or repository you can still access this new repository using the old name.]

When a URI is misused as a URN, it leads to confusion in the best
case.  What if someone else later takes over the domain/repository
name?  (This may possibly not work with GitHub, but with some
providers, it may. Or it may with GitHub in the future.)

[...]

Marc