Email list hosting service & mailing list manager

SRFI-metadata-syncing SRFI? noosphere@xxxxxx (08 Nov 2020 21:50 UTC)
Re: SRFI-metadata-syncing SRFI? Vladimir Nikishkin (09 Nov 2020 01:00 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 09:41 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 16:15 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 16:36 UTC)
(missing)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 20:35 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 20:57 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 21:05 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 23:41 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (10 Nov 2020 07:53 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 23:45 UTC)
Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx (09 Nov 2020 20:50 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 21:12 UTC)
The funnel pattern Lassi Kortela (09 Nov 2020 21:30 UTC)

Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx 09 Nov 2020 23:45 UTC

On Mon 09 Nov 2020 10:57:15 PM +02, Lassi Kortela wrote:
>
> A further benefit of storing in the Scheme implementation's repo is that
> future source releases (tar files) will automatically contain info that
> is up to date for that release. So even if we lose the version control
> history, anyone having the tarball for a release can retrieve the
> metadata. We've found and resurrected quite a few old Scheme
> implementations for the Docker containers, and empirically, the tarballs
> are by far the most resilient format for long-term archival.
>
> If the standardized metadata files take off, a future aggregator could
> read them and then merge in the file containing missing information from
> old implementations. Does this sound reasonable?

This sounds reasonable to me.  I was just against scraping unstructured
data as a long-term solution.  As long as the data that's scraped is
structured and designed to contain desirable metadata, then I have no
objections to storing it in the implementation's tar file.

And, like you say, it is a good way to make sure the metadata is
archived in an authoritative location for future use.

  --Sergey