요약

  • RFC 2016은 고수준 인터넷 활동을 활성화 데이터, 타깃, 경험 정보, 스크립트, 응답 필터를 담은 Uniform Resource Agent로 패키징하여, 그 활동을 공유·수정·재실행할 수 있도록 했다.
  • 이식 가능한 객체는 여전히 자신의 타입을 구현에 매핑하고, 런타임 의존성을 공급하고, 로컬 또는 원격 타깃을 활성화하고, 응답을 해석하는 URAgency에 의존했다.
  • 따라서 저장된 명세나 성공적인 실행은 의도된 조율에 대한 기록일 뿐이었다. 그것은 승인, 의미적 안정성, 올바른 실행, 재현 가능성 또는 완료를 증명하지 않았다.

RFC 2016은 지금도 자세히 읽을 가치가 있는 구분에서 시작한다. 사람은 모든 프로토콜과 자원 선택을 클라이언트 애플리케이션에 박아 넣지 않고도 필요—메일링 리스트 구독, 여러 서비스 검색, 결과 수집—를 기술할 수 있어야 한다. 제안된 Uniform Resource Agent, 즉 URA는 지속적인 활동 기술이었다. 복사하고 수정한 뒤 나중에 호출할 수 있었다. 서로 다른 구현이 하나의 가상 구조를 공유할 수 있었다.

그 이식성은 실재했지만 경계가 있었다. RFC는 실행을 URAgency라 불리는 형식적 환경에 할당했다. 에이전시는 어떤 URA 타입을 처리할 수 있는지 선언하고, 구현과 공통 구조 사이를 번역하며, 활성화 방법을 알고 런타임 요구사항을 충족했다. 필수 메서드에는 검색과 실행이 포함되었다. Pascal 바이너리와 해석 스크립트는 매우 다른 기계 장치를 요구하면서도 같은 넓은 종류의 활동을 표현할 수 있었다. 객체가 활동을 기록했고, 에이전시가 그것을 작동 가능하게 만들었다.

객체가 담은 것

이 아키텍처는 URA를 여섯 부분으로 나눴다. 헤더는 타입을 식별했다. 활성화 데이터는 호출자가 공급해야 하는 값을 기술했다. 타깃은 URL이나 URN을 통해 자원을 지명했다. 경험 정보는 이전 실행 날짜나 이미 발견된 URL을 보존할 수 있었다. 활동 스크립트 또는 프로그램은 조건부 단계, 순서 지정, 스케줄링을 제공했다. 응답 필터는 응답을 재포맷하거나 관련성을 판단했다.

이 필드들은 작업을 단일 버튼보다 더 이해하기 쉽게 만들었다. 동시에 의미가 변할 수 있는 지점을 드러냈다. 활성화 템플릿은 공급된 값이 승인되었다는 것을 확립하지 않았다. 타깃은 인접 호스트, 미러 또는 원격 URAgency를 사용하도록 교체될 수 있었다. 경험 데이터는 이후 실행을 개선할 수 있지만 낡은 가정을 실어 나를 수도 있었다. 스크립트는 하위 활동을 실행할 수 있었다. 필터는 서비스 출력을 사용자가 보는 결과로 바꿀 수 있었다.

RFC 2016의 메일링 리스트 예는 인스턴스가 필요한 것을 캡슐화하고 구독 결과를 식별할 수 있다고 말한다. 이것은 설계상의 약속이지 리스트 서버로부터의 독립적인 영수증이 아니다. 요청과 주장된 결과 사이에는 타깃 선택, 프로토콜 동작, 런타임 상태, 출력 해석이 놓여 있다.

에이전시가 제어 표면이었다

원격 활성화는 이 구분을 더 선명하게 만들었다. URAgency 자체가 타깃이 될 수 있었고, 하나의 URA가 다른 URA를 호출할 수 있었으며, 최상위 URA가 하위 활동을 조율할 수 있었다. 명세를 이동시키는 것은 권한을 제거하지 않았다. 그것은 서로 다른 매핑, 인터프리터, 라이브러리, 자격 증명, 네트워크 위치, 타깃 대체를 사용할 수 있는 여러 에이전시에 결정을 분산시켰다.

Silk 프로토타입은 이 의존성을 드러내 보였다. RFC는 Silk Desktop Internet Resource Discovery 인터페이스를 통해 실행되는 Tcl URA를 기술한다. 사용자는 활동 인스턴스를 보관하고, 활성화 값을 공급하고, Tcl 스크립트를 추가할 수 있었다. 샘플 코드는 서비스 엔드포인트를 하드코딩하고, HTTP 요청을 제출하고, 정규 표현식으로 반환된 HTML을 파싱했다. 그 주석은 미완성 부분과 취약한 오류 보고를 인정하고 있었다.

이 샘플은 광범위한 채택의 증거가 아니라는 점에서 정확히 가치가 있다. 그것은 하나의 프로토타입에서 실행이 무엇을 요구했는지 보여 준다. 호환되는 인터프리터, 도달 가능한 서비스, 사람 대상 페이지에 대한 가정, 결과와 실패를 구분할 만큼의 오류 처리.

사람이 읽는 출력은 취약한 API였다

RFC 2016은 서비스가 사람은 거의 눈치채지 못하는 방식으로 표현을 바꾸면서 그 출력을 파싱하는 소프트웨어를 깨뜨릴 수 있다고 명시적으로 경고한다. 당대의 Leslie Daigle과 Sandro Mazzucato의 논문도 같은 점을 지적한다. HTML에서 정규 표현식으로 추출하는 것은 시각적 서식이 바뀌면 실패한다. 그들의 해법—기계 지향 서비스 입구 또는 공급자 관리 에이전트—은 문제를 인식했지만, 오래된 활동을 스스로 검증 가능하게 만들지는 않았다.

따라서 응답 필터는 해석적 권한을 지녔다. 그것은 오류 페이지를 버릴 수 있고, 오해를 부르는 패턴을 받아들일 수 있고, 부분 출력을 성공으로 표시할 수 있었다. 실행 영수증은 실행이 시작되었다는 것만 증명한다. 프로세스 종료는 하나의 런타임이 멈췄다는 것만 증명할 수 있다. 나중에 같은 URA를 재현하더라도 여전히 다른 타깃에 도달하거나, 바뀐 표현을 받거나, 다른 의존성을 적재할 수 있었다.

RFC 2016은 1996년 10월에 Experimental로, Legacy 스트림에서 발표되었다. 그 전신 초안과 Silk 자료는 표준 트랙의 승리나 배포 역사가 아니라 하나의 아키텍처 실험을 확립한다. 그것을 오늘날의 AI 시스템 계보에 끌어들일 필요는 없다. 그 좁은 역사적 기여가 더 강력하다. 고수준 활동을 이식 가능하게 만들면서 실행, 대체, 해석은 특정한 곳에 남겨 두었다는 것이다.

그 결과 나오는 질문은 객체가 내구성 있는지 여부가 아니다. 에이전시가 선언된 필요에서 시작해 승인된 입력, 해결된 타깃, 실행 가능한 의존성, 관측된 응답, 그리고 검토를 거쳐도 의미가 유지되는 결과에 이르는 방어 가능한 연쇄를 만들어 낼 수 있는지가 문제다.

출처