Just read through this properly and it sounds like a step into the future (or present).
The part about cloudifying/centralizing @settings would be friggin fantastic. sFTP might be nice to have for people behind restrictive firewalls. Great job, thank you for your contributions. On Sunday, September 24, 2017 at 4:41:02 PM UTC-4, Terry Brown wrote: > > The new leo_cloud plugin allows subtrees within a .leo file to be > stored in the cloud. It should be possible to support various cloud > platforms, currently git is supported (i.e. you can use GitLab or > GitHub or your own remote git server). > > A leo_cloud subtree has a top node with a headline that starts with > '@leo_cloud'. The rest of the headline is ignored. The body of this > top node is used to describe the cloud service, e.g.: > > type: Git > remote: g...@gitlab.com:tnbrown/leo_cloud_storage.git > local: ~/.leo/leo_cloud/gitlab_leo_cloud_storage > ID: shortcuts > read_on_load: ask > write_on_save: ask > > The first three lines can be repeated with different IDs to store > different subtrees at the same remote cloud location. > > read_on_load: / write_on_save: can be yes, no, or ask. If it's not one > of those three, there's a warning dialog. > > There's also a file system backend, which would look like this: > > type: FileSystem > root: ~/DropBox/leo_cloud > ID: my_notes > read_on_load: ask > write_on_save: ask > > The FileSystem backend was meant to be for development, but of course > if you map it into a folder that is sync'ed externally, as shown above, > it can serve as a cloud adapter too. > > In addition to the Git and FileSystem cloud types it should be possible > to add many others - Google Drive, OneDrive, DropBox, AWS, WebDAV, > sFTP, whatever. > > Note: https://gitlab.com/ gives you free private repos., in case you > didn't know. > > The data stored is basically headline, body, and uA (unknown > attributes). The caveat is that it must be JSON serializable, this is > to avoid pickle flavor issues. I don't think this will cause problems > except for legacy datetime objects from the todo.py plugin and set()s > in the tags plugin. I think both can be fixed easily - a custom JSON > writer can write datetime as iso string time and sets as lists, and the > tags plugin can coerce lists to sets. I think the todo.py plugin > already reads iso string time values. > > My intended use was a common synchronized todo list across machines, > which this achieves. (note to self, make sure todo icons are refreshed > properly). > > An unintended bonus is that you can use it to sync. your settings > across machines easily too. Because Leo is brilliant ;-), this: > > @settings > @keys > @leo_cloud > @shortcuts > > "just works", so now your shortcuts etc. can be stored on a central > server. > > Lightly tested, but seems to work - testing and other feedback > appreciated. > > Cheers -Terry > > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
