lkn
/
ollie
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

doc: add Architecture section clarifying 9P/D-Bus dual-backend design

This commit is contained in:
Ollie Agent 2026-07-18 16:16:22 +02:00
parent f434e70849
commit b620ccca4f
1 changed files with 17 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
README.md
View File

@ -91,13 +91,26 @@ Monorepo with Git submodules. Each submodule has its own Go module (except `el`
---
## Architecture
Ollie has two session manager backends that run side-by-side. Both embed the same core library and expose the same features; they differ in interface philosophy and deployment context.
| | 9P (`olliesrv`) | D-Bus (`ollied`) |
|---|---|---|
| Interface | Synthetic filesystem | Desktop bus methods + signals |
| Best for | Scripts, remote access, containers, multi-agent | Desktop apps, KDE integration, GUI frontends |
| Network | Native (mount over TCP) | Local session bus |
| Dependencies | None beyond Go runtime | D-Bus daemon, desktop session |
Use whichever fits your environment — or both at once.
---
## 9P: everything is a file
The 9P filesystem server (`olliesrv`) exposes the entire agent runtime as a synthetic filesystem. This is not a convenience wrapper — it is the primary interface, and it provides architectural benefits that no RPC or REST API can match.
The 9P server exposes the agent runtime as a synthetic filesystem. Every session is a directory; every operation is a read or write.
### Why a filesystem?
Every session is a directory. Every operation is a read or write. There is no client library, no SDK, no protocol buffer — `echo`, `cat`, `tail`, and `rm` are the API.
There is no client library, no SDK, no protocol buffer — `echo`, `cat`, `tail`, and `rm` are the API.
```sh
# Create a session