Łączenie warstw

Otwarte pytanie

Trzy warstwy istnieją w prawdziwym życiu równocześnie. Mam osobisty KMS, pracuję w zespołowym KMS-ie i wbudowuję aplikacyjne KMS-y w produkty. Teraz są to osobne systemy, które ręcznie mostkuję — kopiując notatkę klienta z zespołowego KMS-u do mojego osobistego, wynosząc osobisty wniosek w dokumencie zespołowym.

Pytanie: jak wyglądałoby, gdyby te systemy się łączyły?

Nie „zlewały się" — mają różne granice zaufania, różne tempa aktualizacji, różne schematy. Łączenie oznacza: współdzielone encje są rozpoznawane jako ta sama rzecz między warstwami; aktualizacje w jednej mogą być wyniesione (za zgodą) w drugiej; wnioski kumulują się przez granicę.

Obecne myślenie

Trzy podpytania, do żadnego nie ma jeszcze czystej odpowiedzi:

1. Tożsamość encji między warstwami

Jeśli Sam jest encją w moim osobistym KMS-ie, w zespołowym KMS-ie i w aplikacyjnym KMS-ie skupionym na BD, czy te trzy strony Sama są tą samą encją? Trzema widokami jednej encji? Trzema niezależnymi encjami, które się linkują? Moje obecne nastawienie to trzy widoki jednej encji — z kanonicznym identyfikatorem encji żyjącym w małym współdzielonym rejestrze i każdą warstwą renderującą własny widok.

Otwarte: kto jest właścicielem rejestru? Pierwszeństwo-warstwy-osobistej wydaje się właściwe (kanoniczny Sam żyje w mojej, a inne warstwy się do niego odnoszą), ale to pęka w chwili, gdy Sam pojawia się w zespołowym KMS-ie, nie pojawiwszy się wcześniej w osobistym.

2. Propagacja wniosków

Jeśli dowiem się czegoś w osobistej sesji, co jest istotne dla decyzji zespołowej, wniosek powinien propagować — ale nie po cichu i nie bez zgody. Obecna najlepsza propozycja: akcja „promuj do" przy każdym wniosku w osobistym KMS-ie, z jawnymi celami (zespołowy KMS, BD-appowy KMS, publiczny) i jednozdaniowym stwierdzeniem tego, co jest promowane i dlaczego.

Zasada fali chce, żeby było to automatyczne. Granice zaufania chcą, żeby było jawne. Kompromisem jest automatyczne wykrywanie, ręczna promocja.

3. Sprzeczność między warstwami

Najcenniejszym zachowaniem międzywarstwowym byłoby międzywarstwowe wykrywanie sprzeczności: „osobista notatka mówi, że Sam skłania się ku zostaniu; notatka zespołowa mówi, że Sam skłania się ku odejściu". Dziś wymaga to, żebym pamiętał obie notatki. Połączony system wyniósłby konflikt.

Ale: sprzeczność między warstwami jest również najbardziej inwazyjnym zachowaniem. Implikuje, że warstwa zespołowa może czytać w warstwę osobistą (lub odwrotnie) wystarczająco głęboko, żeby porównywać twierdzenia. Tutaj asymetria kierunkowa z ryzyka międzywarstwowego ściera się z ambicją wykrywania sprzeczności w obu kierunkach.

Znane pozycje

• Odpowiedź osobistego KMS-u: linki międzywarstwowe są pierwszoklasowe, ale propagacja jest jednokierunkowa (osobisty KMS czyta z innych warstw; nigdy nie pisze do nich bez jawnej promocji).
• Odpowiedź zespołowego KMS-u: izolacja tenantów; łączenie między tenantami jest zakazane z założenia. Osobisty KMS użytkownika siedzi poza granicą tenanta.
• Inni praktycy: nie widziałem poważnego opublikowanego opracowania łączenia międzywarstwowego. Tana, Anytype, Roam wszystkie gestykulują w jego stronę; żaden, którego używałem, tego nie rozwiązuje.

Co by to rozstrzygnęło

Działający prototyp, w którym jedna współdzielona encja (Sam) jest renderowana poprawnie w osobistym, zespołowym i BD-appowym KMS-ie, z maleńkim współdzielonym rejestrem, i w którym mogę odpowiedzieć na „co każda warstwa mówi o tej encji?" w jednym zapytaniu bez ręcznego sklejania. To następny eksperyment.