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:49 UTC)
Re: SRFI-metadata-syncing SRFI? Lassi Kortela (09 Nov 2020 21:11 UTC)
The funnel pattern Lassi Kortela (09 Nov 2020 21:30 UTC)

Re: SRFI-metadata-syncing SRFI? noosphere@xxxxxx 09 Nov 2020 20:35 UTC

On Mon 09 Nov 2020 10:42:33 PM +03, Lulu wrote:

> I'm all in favour of a standardised, minimal way of expressing SRFI
> support, or maybe even general features (eg 'this implementation has
> native threads') for each implementation. It's worth noting that this
> won't be possible for unmaintained implementations, but fortunately their
> respective feature sets aren't likely to change any time soon. :-)

But it could be possible if such information is not gleaned from their
tar files but from a URL.

The metadata consumer could be pointed to such a URL, which could be
hosted anywhere, and does not need the intervention of an absent maintainer.

Even if it was gleaned from their tar files, unmaintained
implementations could be unarchived and then rearchived with the
requisite metadata, so future queries of it could succeed, and so that
ways of getting metadata could be consistent across implementations.

 --Sergey