Sea Sync Mechs

I said, the admin savvy sailor can cache whole sites onboard and then proxy dns to browse these while at sea.

We imagine the sailor has a site they write and another site they read. And for each they have on board a write cache and a read cache which they rely on while at sea. For each they have a bulk update called "copy" which moves all bits and a Mech based incremental update called "sync".

Depart by copying both down, read to read cache and write to write cache. Once at sea depend only on sync.

Remote read by sync the read cache then read locally.

Remote write by editing the write cache then sync write.

Remote fork from read to write caches then sync write.

Return to fast network by copying up and down, read cache up to read and write down to write cash.

Remote read and write should convert to Mech get and put. Remote fork should also be easy to sync but will require careful reasoning.

We scp ward.dojo.fed.wiki to dojo.localhost. This was slow. Probably should use tar or zip somehow.

Had to login using localhost's security.

Revise the flag for dojo.localhost to avoid confusion.

We create empty site copy.dojo.localhost. Then cp dojo.localhost pages and assets to make 100% localhost simulation to facilitate Mech development. We discard stale sitemaps so they will be recomputed.

We try diff of two Journals knowing that this is at the root of our sync operation.

We model copy on return with cp.

We handle this one case first using modification times rather than diff and working with these specific pages.

The working implementation requires GET pass named state on to the server-side. In this case it is debug which passes the shift-click state to the server and recent the state output of DELTA have.

We had imagined that get would go to the origin server or perhaps the remote host of the page offering the Mech. This could prove to be useful in most cases but for here we provide the address of the site from which we will sync.