요약

  • RFC 984은 언제나 연결된 보관소에 메일의 안정적인 전체 상태를 두고, 한 사람의 여러 PC가 지역 사본을 보유하다 연결 시 맞추는 방식을 제안했다.
  • 보통 약 100바이트인 요약 기록으로 작은 디스크에도 전체 메일 목록을 둘 수 있었다. 배치 모드에서는 오프라인 작업을 모아 두며, DMSP는 작업의 원자성과 명시적 확인을 요구했다.

사무실 PC의 전원을 끈다. 집에도 PC가 하나 있다. 운반할 수 있는 기종이라면 자동차 뒷좌석에도 올라간다. David Clark와 Mark Lambert는 1986년 5월 PCMAIL 제안에서 이런 이동을 실제로 상상했다. 그동안 들어오는 편지는 어디로 가야 할까. 두 사람은 디스크가 넉넉하고 늘 네트워크에 있는 보관소를 답으로 삼았다. 컴퓨터는 오가지만 메일의 주소는 자리를 지킨다.

PC는 자유로웠지만 저장 공간에는 인색했다. 한 사람이 직장과 집에 각각 한 대를 둘 수 있었고 기계를 옮길 수도 있었다. 원문이 든 전형적 PC는 메모리가 1메가바이트 미만, 플로피 디스크 용량은 약 360킬로바이트였다. 모든 편지의 본문을 들고 다니기에는 턱없이 작다. 대신 편지의 목록을 들고 다니게 했다.

메시지는 요약 기록과 본문으로 갈라졌다. 요약은 보통 약 100바이트이며 본문 길이에 따라 커지지 않는다. 식별자, 크기, 유용한 헤더 항목, 상태 표시가 들어간다. PC는 전체 요약을 저장하고, 본문은 디스크에 자리가 생길 때 보관소에서 가져올 수 있었다. 내용 전체를 갖기 전에도 어떤 편지가 왔는지 알 수 있었다. 작은 목록표가 작은 기계의 시야를 넓혔다.

보관소는 전체 상태를 갖고 각 PC는 지역 상태를 갖는다. 늘 연결된 대화 모드라면 변화가 바로 반영되고 새 메일도 바로 들어온다. 연결이 드문 배치 모드라면 PC가 오프라인에서 행동을 대기열에 쌓고, 다음 접속 때 보낸다. DMSP가 메일 조작과 동기화를 담당했다. 회사 PC와 집 PC는 한동안 같은 우편함을 서로 다른 시점에서 바라본다.

다시 만날 때는 계산이 정확해야 한다. DMSP 작업은 전부 성공하거나 전부 실패한다. 명시적인 확인이 없으면 실패로 취급한다. 삭제 도중 연결이 끊겼다고 두 사본이 서로 다른 사건을 기억하게 둘 수는 없다. 보관소는 각 PC가 놓친 변경도 기록했다. 문서 속 구현에서는 일주일 동안 접속하지 않은 PC를 비활성으로 표시하고, 돌아오면 작은 변경을 하나씩 따라잡게 하는 대신 전체 상태를 다시 보냈다.

RFC 편집부 기록은 이 예비 제안이 1986년 5월에 나왔고 나중에 RFC 993으로 대체됐다고 적는다. 역할 분담은 선명하다. 보관소는 기억하고 PC는 움직이며, 100바이트짜리 표는 짐을 줄이고 프로토콜은 끊긴 사이의 행동을 정산한다. PC가 퇴근해도 우편함은 야근했다.