Maybe relevant: http://techcrunch.com/2013/03/19/google-launches-drive-realtime-api-to-let-developers-build-apps-with-real-time-collaboration/
On Thu, Mar 21, 2013 at 4:59 PM, Ville M. Vainio <[email protected]> wrote: > DB like storage for leo documents comes up every 6 months. Technically, it > makes sense in many ways, but it's about payback vs. implementation work. > > If we could combine this to making leo more parallelizable (so that e.g. > save could happen in other process), it could be a boon. > > > On Thu, Mar 21, 2013 at 2:59 AM, David McNab <[email protected]>wrote: > >> Hi all, >> >> I've been a profoundly grateful user of Leo since it was first announced. >> While I use it mainly for programming, it has come in extremely handy for >> other tasks, such as building university essays. >> >> I'm writing now to ask what the thinking is regarding getting a >> cloud-ready version of Leo up and running. >> >> I'm thinking about various usage patterns, such as: >> >> - Auto-sync style clouds like Dropbox - Leo can monitor the local >> copy of the file, and if changed outside of Leo, reload it and update the >> running instance - this is a bit crude, and vulnerable to race conditions, >> but likely not too hard to implement >> >> - Client-server style - users can install some server-side code under >> Apache which lets n running instances of Leo desktop client to talk via >> http to a server, which mediates reads/writes/creates/deletes of nodes >> >> - Leo in the browser - here, it's well worth looking at the excellent >> Checkvist cloud-based outliner at www.checkvist.com. It's got some >> great cloud ideas Leo could borrow. It's just a matter of whether Python >> in-browser frameworks like Pyjamas are up to the job, versus how hard it >> would be to implement Leo in >> <brain-haemorrhage>Javascript</brain-haemorrhage> >> >> I'm of the strong opinion that, whichever way Leo goes, it needs to move >> away from the XML .leo file as its principal storage format, and move >> towards database storage, with a one-node-per-db-record mapping and support >> for automatic acquisition/release of node locks. IMHO, the.leo file should >> be put out to pasture and work just as a very handy import/export format. >> It's still a great way to pack a whole heap of (non-thin) files together >> with coherent structure. >> >> Thoughts? >> >> Cheers >> David >> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/leo-editor?hl=en. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/leo-editor?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
