U tohoto se prosím ještě zastavme. Já bych to řešil právě tou session. Přijde mi to takové intuitivnější. Aktor A + Zpráva + Session komunikace (kterou dodá obsluha). Tedy to, zda je ta zpráva od aktora B, nebo C(, nebo dokonce B jiná session) řeší runtime, a nikoliv vlastní Aktor. Aktor je jen a pouze vlastní logika. Takto si to představuju. V čem bych mohl narazit?
Proč bych měl chtít, pokud jsem tě pochopil dobře, aby aktor nepřeskakoval mezi klienty?
Já bych si přestavoval, že ten aktor je do značné míry bezestavový. Respektive ten stav je uložen mimo, ve službách a v session. Ale samozřejmě si rád vyslechnu proč je to blbej nápad :-)
Takže vlastně tvoje představa je spíš bližší HTTP než aktorovému systému ala CSP
Jako proč ne? Klidně to tak udělat můžeš, ale pravděpodobně si tím na sebe uvalíš omezení, která ti pak neumožní dělat některé věci, které se v opravdovém aktorovém systému dělat dají, nebo budou zbytečně složité. Pravděpodobně se dostaneš k "něčemu podobnýmu RESTu" a hlavní otázka pak je, proč to vůbec dělat a nepoužít REST
Pokud bych měl říct konkrétněji, co mi přijde jako nevýhody takového řešení: pokud má runtime jakýmkoli způsobem manipulovat s komunikačními akty (např. je zhlukovat do těch sessions), tak:
1. musí té komunikaci rozumět (minimálně musí umět poznat začátek a konec)
2. buď teda budeš muset mít natvrdo jeden "metaprotokol" (např. zprávy "BEGIN" a "END" budou muset být součástí každé komunikace
3. nebo budeš muset nějak do runtimu nahrát popis protokolu
4. připravíš se o některé možnosti dynamického dispatche zpráv - u jednotlivých izolovaných zpráv můžeš třeba jednu konkrétní zprávu přehodit na jinýho aktora. Tady to nebudeš moct udělat, protože co by se pak dělo se session?
Už tohle je imho úplně zbytečný opruz, který tě bude stát jenom práci navíc, bude tě svazovat a nevidím žádný přínos, který by přinášel oproti klasice (neříkám, že neexistuje, jenom, že si ho teď neumím představit).
V klasickém aktorovém systému se můžeš ty, jako autor aktoru, rozhodnout, jestli v tu kterou chvíli komunikuje stylem "session" nebo stylem "ad hoc zpráva". Prostě kód napíšeš tak nebo tak. Pokud budeš
muset použít session, budeš mít úplně zbytečnou režii u komunikací, které session nijak nevyužijí (např. máš aktor, který čte stav tlačítka a když dojde ke změně stavu, pošle o tom zprávu jinému aktoru - to je bezestavová, jednozprávová komunikace, session tam k ničemu není).
Bez session:
A->B: switch=on
...
A->B: switch=off
S vynucenou session:
A->B: BEGIN
A->B: switch=on
A->B: END
+ režie toho, že někdo někde (úplně zbytečně) drží informace o té sešně.
Nevím, prostě se mi to intuitivně nezdá. Není to imho cesta správným směrem. Pokud chceš pochopit, na co jsou aktory dobré, drž se prostě CSP nebo toho, jak to má Erlang.