Summary

  • OpenStreetMap은 2009년 4월 17일 API 0.6 이전 중 편집 API를 읽기 전용으로 바꿨다고 알렸다. 때로는 완전히 쓸 수 없을 수도 있었다. 기여자는 수정을 저장하지 못했고 Potlatch가 멈췄으며 다른 편집 프로그램도 새 버전에 맞춰야 했다.
  • 새 API는 수정마다 changeset을 요구하고, 지도 요소 버전을 확인하고, 공개 편집에 숫자 사용자 ID를 더했다. 한 번의 차이 업로드는 원자적으로 처리할 수 있지만 여러 요청에 걸친 changeset 전체는 그렇지 않았고 API에서 통째로 되돌릴 수도 없었다.

지도의 잘못된 길을 찾았다. 그러나 고친 길을 서버에 보내는 문이 닫혀 있었다. OpenStreetMap은 2009년 4월 17일 공지에서 API 0.6 이전 동안 편집 API가 읽기 전용이라고 밝혔다. 때로는 API가 완전히 중단될 수도 있었다. 수정을 데이터베이스에 저장할 수 없었고 웹 편집기 Potlatch도 꺼졌다. 작업은 20일 월요일 중 끝날 것으로 예상했으며 다른 편집 프로그램은 호환 버전으로 올리라고 했다. 공지의 시한은 당시의 예상이었지 모든 저장 경로가 돌아온 시각의 기록은 아니었다.

그 대가로 바꾸려던 것은 수정의 단위였다. 프로젝트의 API 0.5에서 0.6으로의 변경 기록은 0.6 발표일을 4월 20일로 적고, 노드·길·관계의 모든 수정을 changeset에 넣도록 했다. 한 묶음은 여러 API 호출에 걸쳐 열어 둘 수 있고 사람이 읽는 설명도 붙일 수 있었다. 흩어진 지도 요소의 변화를 한 작업의 맥락으로 볼 수 있게 된 것이다.

하지만 한 묶음이라고 해서 한 번에 되감기는 작업은 아니었다. 문서는 changeset 전체가 원자적이지 않으며 API로 한꺼번에 롤백할 수 없다고 명시한다. 한 요청에 담긴 차이 업로드는 원자적으로 처리할 수 있다. changeset은 작업의 내력을 모으고, 단일 요청은 한 차례 기록의 성패를 묶는다. 고장 난 뒤 무엇을 다시 고쳐야 하는지 판단할 때 이 차이는 중요했다.

버전 번호는 두 사람이 같은 길을 고칠 때 작동했다. 편집 프로그램은 지도 요소를 내려받으며 받은 버전을 저장할 때 다시 보낸다. 누군가 그 사이 더 새 버전을 기록했다면 서버가 오래된 자료에 기반한 수정을 거부한다. 편집기는 충돌을 알리고 현재 지도를 다시 받아오도록 해야 했다. 기록을 보기 좋게 만든 변화가 동시에 오래된 화면의 덮어쓰기를 막는 작업 규칙이 됐다.

누가 수정했는지를 남기는 방식도 달라졌다. 이전 API는 사용자가 바꿀 수 있는 표시 이름을 돌려줬고 이름 변경 기록은 남지 않았다. 0.6은 공개 편집에 숫자 계정 ID를 함께 넣었다. 그렇다고 예전 익명 수정에 빠져 있던 ID가 뒤늦게 만들어지는 것은 아니었다. 새 규칙은 앞으로의 공개 작업을 더 단단히 연결했고, 과거의 빈칸은 그대로 남겼다.

프로젝트가 보존한 이전 테스트 페이지는 중앙 서버 밖의 일을 드러낸다. 편집기 개발자에게 시험용 API가 열렸고 changeset 생성, 오래된 버전의 거부 메시지, Potlatch와 JOSM의 동작, 복제 도구를 확인하라는 목록이 나왔다. 일부 오래된 JOSM은 0.6과 함께 작동하지 못했다. 서버 한 곳의 변경이 지도를 그리는 여러 도구의 호환성 문제로 번진 셈이다.

실제 데이터베이스도 옮겨졌다. OpenStreetMap Foundation의 5월 12일 이사회 회의록은 MySQL 시스템을 PostgreSQL 서버로 바꿨고 이전 단계 일부를 다시 실행하느라 예상보다 오래 걸렸다고 적는다. 남은 수정, 감시 작업, 추가 디스크도 논의됐다. 늦어진 이유는 보이지만 각 편집 기능이 돌아온 정확한 시각은 이 기록에 없다.

지도는 작업을 더 잘 기억하게 됐다. 그러기 위해 당장은 아무도 새 작업을 저장하지 못했다. 기여자는 기다렸고 도구 개발자는 코드를 맞췄으며 서버는 오래된 버전을 거부하고 관련 수정을 묶는 규칙을 배웠다. 같은 지도를 그려도 저장 버튼 뒤의 약속은 달라졌다.

원자료