In octopus you didn't have to "save" the state. The window system was kept running at a server, including the layout you were using. It was nice, and I miss it. II'll have to do something about it when I get some time.
> On 3 Mar 2018, at 20:13, Steve Simon <st...@quintile.net> wrote: > > i am pretty sure nemo’s octopus window system in planB had a way to save and > restore its state so you could migrate your sessions from one terminal to > another. > > also, i would have thought you could build a windows drawterm which also > included the code from exportfs so you could use 9fs and aan to get at the > files on your windows box. > > one bit that rangboom added was to be able to mount a filesystem on windows > from plan9. the windows IFS subsystem id not simple or friendly. > > personally i think this idea will become more and more important as we get > fiber to the home, local storage will become a thing of the past. > > -Steve > > >> On 3 Mar 2018, at 17:41, hiro <23h...@gmail.com> wrote: >> >> I have 9front running on a server at ovh france, my workstation is a >> windows 7 machine with drawterm in autostart. drawterm itself is run >> with -p option so that it can make use of AAN, which recovers broken >> TCP connections e.g. after resuming from sleep in the mornings or >> during any network state changes (windows frequently resets TCP >> connections even if it wouldn't be needed). >> >> This way my rio windows always stay open on windows, even though all >> the windows network shares, vnc sessions, ssh stuff break every time >> and have to be painstakingly reconnected. >> If I could make the drawterm files accessible to windows (you rangboom >> people please step forward), then I could mount the cifs share on >> 9front, and then mount that on windows via drawterm to have more >> stable connectivity to my windows shares. >> I hope the rangboom people will share their technology so we won't >> have to port cifsd to drawterm instead. >> >> if i am in the train and on my laptop i can log into the same server. >> i have a little LTE wifi router that maintains a tunnel to france so i >> can keep on using the same IP when my laptop and phone leave the house >> (actually AAN wouldn't even be needed for mobility if it wasn't for >> crappy low NAT timeouts during temporary connection problems and >> sleep). >> >> Since my laptop is a separate terminal with it's own rio session, >> sadly the rio windows are not synced. As Russ mentioned though i have >> access to the same files. >> You have to be careful with open sam windows in case they have unsaved >> changes, but the dropbox people have the same merge conflicts. As a >> windows user I learned to save my files instead. :) >> >> It would be nice to have less local state (i.e. rio windows, devdraw). >> Multiple approaches could be used quite easily. >> One of them that is very curious is mycroftiv's ANTS project, which >> separates the state of rio rc windows from the graphical environment. >> >> acme also has state-saving functionality. it needs to be killed or >> told to though. in my scenario it wouldn't get killed cause my session >> survives, and i don't want it to close on one side normally :) >> >> no idea if sam has anything for this, so right now i advocate >> discipline instead. > >
