요약

  • Prospero는 사용자와 관리자가 원격 시스템에 그대로 남아 있는 파일과 인덱스 위에 가상 디렉터리 뷰를 만들 수 있게 했습니다. 기반이 되는 데이터를 옮기거나 해석하는 대신 참조를 정리했습니다.
  • 1993~94년 기록은 Archie, Gopher와의 연계, WAIS와 웹 자원에 대한 계획을 설명하지만, 2005년의 RFC는 이 프로토콜이 널리 구현되지 않았다고 밝힙니다.

디렉터리는 관점이 될 수 있었다

파일 디렉터리는 보통 파일을 저장하는 기계의 속성처럼 보입니다. Prospero는 다른 답을 제안했습니다. 디렉터리가 여러 기계에 걸쳐 조립된 뷰이고, 사용자의 조직 방식이 자원 자체와 분리되어 있다면 어떨까 하는 발상이었습니다.

이 구분은 실용적인 문제였습니다. 1990년대 초반에 사람들은 Archie로 FTP 아카이브를 검색하고, Gopher 메뉴를 둘러보고, WAIS 데이터베이스에 질의하고, 떠오르는 월드 와이드 웹을 따라갈 수 있었습니다. 이 시스템들은 서로 다른 종류의 정보를 서로 다른 인터페이스로 내보냈습니다. 유용한 항목을 찾는다고 해서 그것이 개인의 작업 지도에 편입되는 것은 아니었습니다. 연구자는 여러 기관에서 가져온 항목으로 이루어진 프로젝트용 디렉터리를 원할 수 있었고, 그렇다고 파일을 새로운 중앙 저장소로 복사하고 싶지는 않았습니다.

Prospero의 가상 시스템 모델(Virtual System Model)이 바로 그 조직화 계층을 공급했습니다. 서버는 자신의 파일시스템 중 선택한 부분에 대한 정보를 공개하거나 다른 데이터베이스의 자료를 노출할 수 있었습니다. 사용자와 관리자는 네임스페이스에 대한 맞춤형 뷰를 만들 수도 있었습니다. 디렉터리 항목은 자원을 가리키면서 자원은 게시자가 두고 있던 곳에 그대로 남았습니다. 네트워크 지도는 개인적이면서 동시에 분산되어 있었습니다. 통합되지 않아도 되는 여러 위치에서 조립된 하나의 일관된 뷰였던 것입니다.

발견과 검색 사이의 계층

이것은 단순히 이름만 다른 Archie가 아니었습니다. Archie는 FTP 아카이브의 파일명과 위치에 대한 인덱스를 만들어 질의가 후보를 찾을 수 있게 했습니다. Prospero는 Archie 데이터베이스를 더 큰 디렉터리 뷰 안의 하나의 출처로 쓸 수 있었습니다. Gopher만 그런 것도 아니었습니다. Gopher의 익숙한 메뉴는 둘러보기용 자료를 정리했고, Prospero 서버는 Gopher 서버를 데이터베이스로 취급해 그 내용을 다른 출처와 결합할 수 있었습니다.

경계가 중요한 이유는 Prospero가 데이터를 이해한다고 주장하지 않았기 때문입니다. 1994년 네트워크 정보 보고서는 Prospero가 검색(retrieval) 메커니즘은 제공할 수 있지만 표시와 사용은 사용자의 응용 프로그램에 속한다고 설명합니다. Prospero에는 별도의 파일 전송 프로토콜이 없었습니다. 접근은 FTP, NFS, AFS 또는 Gopher를 통해 이루어질 수 있었고, 로그인 기반 서비스에는 Telnet이 쓰였습니다. Prospero는 클라이언트가 자원이 어디에 있고 어떻게 도달할 수 있는지 판단하도록 도울 수 있었지만, 파일이 최신이고, 읽을 수 있고, 인가되어 있고, 유용하다는 것을 보장하지는 않았습니다.

이 분리 덕분에 설계는 확장 가능했습니다. 디렉터리는 여러 서비스를 공용 저장 시스템이나 공통 콘텐츠 형식으로 강제하지 않고 모을 수 있었습니다. 동시에 실제 작업은 가장자리에 남았습니다. 포인터는 대상보다 오래 살아남을 수 있고, 원격 서버는 접근을 거부할 수 있으며, 클라이언트는 여전히 찾아낸 것을 가져오고 표시할 올바른 방법이 필요했습니다.

규칙과 경계를 갖춘 네트워크 지도

Prospero 디렉터리 요청은 프로젝트가 설명한 신뢰성 있는 메시지 전달 계층을 거쳐 UDP로 실행되었습니다. 설계에는 객체, 디렉터리, 인덱스에 대한 접근 제어도 포함되어 있었습니다. 1994년 보고서는 클라이언트 주장(client assertion)과 신뢰된 포트부터 암호, Kerberos 버전 5까지 여러 인증 선택지를 나열합니다. 이 옵션들은 가상 디렉터리가 반드시 열린 공개 목록은 아니었음을 보여줍니다. 관리자는 누가 특정 부분을 열람하거나 사용할 수 있는지 결정할 수 있었습니다.

prospero URL 스킴은 이 분리를 드러냈습니다. URL은 Prospero 서버가 해석하는 호스트별 객체를 이름 짓습니다. 그 서버에 접속하면 기반이 되는 접근 방법을 반환할 수 있었고, 이는 또 다른 URL로 표현될 수 있었습니다. 문자열 자체는 대상이 존재한다거나 사용자가 검색할 수 있다는 약속이 아니었습니다. 이름 안의 슬래시조차 계층적 의미를 보장하지 않았습니다. 객체를 정의한 것은 문장 부호가 아니라 서버였습니다.

이것은 창고보다는 지도에 가깝습니다. 지도는 장소들을 연결하고 독자에게 경로를 알려줄 수 있지만, 장소를 소유하지도 않고 길이 열려 있다고 보장하지도 않습니다. Lu Heng의 디렉터리와 분산된 권위에 관한 노트를 Prospero 설계자들에 대한 증거가 아니라 편집적 렌즈로 읽으면 이 구분을 명확히 유지하는 데 도움이 됩니다. 포인터의 목록은 그것이 기술하는 자원에 대한 통제권이 아닙니다.

야망은 채택보다 기록하기 쉬웠다

1994년 상태 보고서에서 프로젝트는 약 50개의 Prospero 서버를 나열했고, 서버와 클라이언트 정보는 1993년 11월에 마지막으로 갱신되었다고 명시했습니다. 이는 프로젝트가 보고한 시점의 추정이지 고유 사용자, 활성 디렉터리, 인터넷 전체의 시장 점유율에 대한 측정이 아닙니다. 같은 보고서는 Archie와 Gopher로의 작동하는 연계, WAIS 인덱스와 웹 문서에 대한 계획을 기술했습니다. 일부 통합은 이용 가능했고, 나머지는 미래의 과제로 남아 있었습니다.

십여 년 후, RFC 4157은 URI 스킴을 보존하면서 이를 Historic 문서로 옮기고 Prospero 프로토콜이 널리 구현되지 않았으며 사용 중인 서버가 거의 남아 있지 않다고 직접 밝혔습니다. 나중의 판정이 설계 실험을 지우지는 않습니다. 다만 역사가 주장할 수 있는 범위를 바꿉니다. Prospero는 사람들이 분산된 자원을 배열할 수 있게 하는 방법을 입증했지만, 광범위하게 배치된 디렉터리 계층이 되지는 못했습니다.

이 결과는 단순한 기술적 결함 이상을 가리킵니다. 개인 지도의 가치는 관리자가 유용한 뷰를 게시하고, 클라이언트가 네임스페이스를 이해하고, 통합이 최신 상태를 유지하고, 사용자가 배울 가치가 있다고 판단하는 데 달려 있었습니다. 설계가 여러 서비스를 우아하게 연결하더라도 여러 커뮤니티에게 다리를 채택하고 유지해 달라고 부탁해야 했습니다.

따라서 Prospero의 지속되는 역사적 질문은 이후의 시스템을 발명했는가가 아닙니다. 발견(discovery)은 하나의 권위적인 전역 인덱스를 만들어야 하는가, 아니면 다른 곳에 보관된 자원 위의 여러 지역적으로 의미 있는 지도를 만들어야 하는가입니다. Prospero는 두 번째 선택지를 구체화했습니다. 그 아키텍처는 조직화와 저장을, 이름 붙이기와 검색을 분리했습니다. 그 좁은 발자국은 좋은 분리만으로는 생태계를 만들 수 없다는 것을 보여줍니다.

출처