앞의 두 글에서 장치 하나를 다뤘다. 자기 화면을 건네고, 그 화면이 설치 없이 도착한다.
현장에는 장치가 하나만 있지 않다. 조타실에는 발전기와 밸러스트와 연료계가 같이 있다. 이 글은 여럿을 한 화면에 모을 때 무엇이 일어나는지다.
보통은 호스트가 결합을 짠다
여러 장치를 한 화면에서 보려면, 대개 앱이 그 결합을 코드로 갖고 있다. 어느 장치의 어떤 값을 어디에 놓을지, 그 버튼이 어느 장치로 갈지를 앱이 안다.
그래서 장치를 하나 더 붙일 때마다 앱을 고친다. 그리고 조합이 빌드 시점에 고정된다. 현장에서 장비 구성이 바뀌면 앱도 다시 나와야 한다.
여기서는 결합이 문서로 내려간다
UI DSL 1.4의 합성 규약은 그 결합을 문서로 내린다. 호스트가 하는 일은 두 가지뿐이다 — 연결을 쥐고 있는 것, 그리고 문서가 이름 부른 상대를 열어 주는 것. 결합 로직이 없다.
문서에는 이렇게 적힌다. 여기에 이 연결이 주는 화면을 넣어라. 저기에 저 연결이 주는 화면을 넣어라.
규약이 정하는 성질이 넷이다.
- 각 장치가 서빙하는 화면을 무수정 그대로 남의 앱 안에 넣는다. 장치는 자기가 합성되는 줄 모른다.
- 임베드된 부분의 조작과 구독이 그 장치로 나간다.
- 실패는 타일 단위로 격리된다.
- 서버를 추가해도 호스트는 바뀌지 않는다.
넷 다 스펙에 적힌 말이다. 그래서 화면에서 재 봤다.
잰 것 — 노드 셋
MCP 노드 셋을 띄웠다. Boiler A, Pump B, Valve C. 각자 자기 화면을 서빙하고, 자기 값을 갖고, 자기 도구를 노출한다. 서로를 모른다.
그리고 세 장치를 한 페이지에 놓는 문서를 하나 썼다. 그 문서에는 무엇이 그려질지 적혀 있지 않다. 어느 연결이 어디에 들어갈지만 적혀 있다.
① 세 타일이 각자 자기 화면으로 그려졌다. 각자 자기 이름, 자기 단위, 자기 색, 자기 값. 앱은 그중 아무것도 쓰지 않았다.
② 타일의 버튼이 자기 서버로만 갔다. 첫 타일의 버튼을 누르면 첫 서버의 값만 오른다. 서버에 직접 물어서 확인했다 — 29→30, 나머지 둘은 그대로. 둘째를 누르면 둘째만, 셋째를 누르면 셋째만.
이게 합성에서 가장 조용히 틀릴 수 있는 자리다. 화면은 제대로 그려지는데 버튼이 엉뚱한 서버로 가면, 증상이 화면에 안 나타난다.
③ 하나를 죽였다. 둘째 노드를 내렸다. 그 타일만 대체 표시로 바뀌고 첫째 타일은 살아 있었다. 페이지도, 그 아래 내용도 계속 그려졌다. 네 장치 중 하나가 꺼진 화면은 세 개가 살아 있는 화면이지 빈 화면이 아니다.
④ 셋째를 추가했다. 문서에 두 자리를 더했다 — 연결 하나, 자리 하나. 그리고 호스트 바이너리의 해시를 추가 전후로 비교했다.
같았다. 재빌드가 없었다.