DenoにおけるPURLサービスの提案

Denoの特徴の一つとして、依存するライブラリの指定にURIを直接指定できるというものがあります。
これは、依存関係解決の複雑さや名前空間の切り分けの点で非常に有効です。実際Deno以外にもGoなどの処理系でも此の方法が採用されています。

モチベーション

ところで、Denoのライブラリに関わらずURIが使用される場面では一つの問題があります。
それは作成したURIの変更が難しいということです。作成したURIが使用されるのは、二つの場合が考えらます。ひとつは、自分が管理するプロジェクトで使用される場合です。この場合は作成済のURIを変更してもプロジェクト全体にたいしてURIの置換を適用すればよいので問題にはなりません。
もうひとつは、自分が管理していないプロジェクトが自分のプロジェクト内のリソースを指定する場合です。自分のプロジェクト内のリソースのURIが変更された場合、その変更をURIを使用しているしているプロジェクトの管理者に連絡し、URIを更新してもらう必要があります。

PURLサービスとは?

この問題を解決するのがPURL (Persistent uniform resource locator) です。これは、URL転送サービスの一種で、PURLによって割り当てられたURIに問合せが来た際に事前に登録しておいた別のURIを30xのステータスコードとともに応答します。

このサービスにより外部プロジェクトの管理者にはPURLによって割り当てられたURIを教えておき、URIを変更する際はPURLが応答すべきURIを更新することで対応するといった対応ができます。

実際、いくつかの国際規格などの重要なプロジェクトでは、その仕様を公開するにあたってPURLを経由したURIで公開しているものがあります。(RSS1.0など)

<?xml version="1.0" encoding="utf-8" ?>
<rdf:RDF 
  xmlns="http://purl.org/rss/1.0/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" 
  xml:lang="ja">

もしDenoがPURLを使用しなかったら?

今後ライブラリ作成者のURI変更により知らぬまに自分のソフトウェアが動作しなくなるなどの障害が考えられます。そうした場合、利用者自らが新しいURIを探し更新する必要があります。しかし、マイナーなライブラリの場合,代替のURLを見つけるのは一般に困難です。
実際Goでは過去に何度か有名なライブラリにアクセスできなくなったことで大量のソフトウェアに影響がでた事例があります。

有名なPURLサービス

1. Internet Archive (旧 purl.org)
   RSS1.0などの国際規格でも採用実績があるPURLサービス
2. deno.land
   厳密にはPURLサービスではないが、URLを転送している。

まとめ

依存しているライブラリがPURLを経由しないURIを指定している場合でも前述のようなトラブルが発生する可能性があります。少数の人間がPURLを利用しても意味がありません。コミュニティ全体でPURLの利用を促進する必要があると考えています。!