Summary
Currently solidos-lite only handles read operations by intercepting fetcher.load(). To complete the Solid experience, we need to support write operations.
Background
In Solid, persistence is core - you edit, it saves. Data islands should support this paradigm.
Proposed Approaches (incremental)
Phase 1: Client-side persistence
- Intercept PUT/PATCH for current page
- Update
<script type="text/turtle"> in DOM
- Persist to localStorage (survives refresh)
Phase 2: Download/export
- Serialize updated HTML with modified data island
- Offer "Save As" to download the file
Phase 3: Server bridge
- Translate writes to raw Turtle PUT/PATCH
- Works with existing Solid servers
- Server stores
.ttl, solidos-lite wraps in HTML
Phase 4: Native server support
- Servers understand HTML+data island as first-class resource
- True persistence without translation
Technical Notes
mashlib uses fetcher.webOperation() for writes - this would need interception similar to how we intercept fetcher.load() for reads.
Related
Eventually data islands should be first-class in Solid servers, eliminating the need for client-side bridges.
Summary
Currently solidos-lite only handles read operations by intercepting
fetcher.load(). To complete the Solid experience, we need to support write operations.Background
In Solid, persistence is core - you edit, it saves. Data islands should support this paradigm.
Proposed Approaches (incremental)
Phase 1: Client-side persistence
<script type="text/turtle">in DOMPhase 2: Download/export
Phase 3: Server bridge
.ttl, solidos-lite wraps in HTMLPhase 4: Native server support
Technical Notes
mashlib uses
fetcher.webOperation()for writes - this would need interception similar to how we interceptfetcher.load()for reads.Related
Eventually data islands should be first-class in Solid servers, eliminating the need for client-side bridges.