Relevant for the git part: see gitarchive.py plugin. At has command alt-x git-dump, that dumps the tree as bunch of flat files (named by gnx) and commits changes to git repository.
On Sun, Mar 24, 2013 at 5:26 PM, Terry Brown <[email protected]>wrote: > On Sat, 23 Mar 2013 04:59:08 -0700 (PDT) > "Edward K. Ream" <[email protected]> wrote: > > > On Wed, Mar 20, 2013 at 7:59 PM, David McNab wrote: > > > > > I'm writing now to ask what the thinking is regarding getting a > > cloud-ready version of Leo up and running. > > > > As Ville says, this is a perennial topic. And for good reason. This is > > one of those "big questions" that it would be useful to discuss at length > > at the Leo sprint. > > Seems to me there's a whole bunch of loosely related issues here: > > 1) performance - save time seems to be the biggest issue - it's not > terrible, but slow to save several large outlines at once. The time > is in the generating of the content of the @<file> plain text files, > so XML / database / cloud is probably not relevant here. A C/++ > helper might help, although it introduces distribution complexities, a > pure python option should be maintained as well. > > 2) Leo data on a server accessible anywhere. In terms of who has > access to what kinds of servers, the simplest and most widely > available way to get this is probably simply keeping Leo files in > DropBox or some similar service. > > 2a) Leo in any web-browser. Either as pure coffee/javascript, or a > front end to python running on a server somewhere. The former would > be easier if only outlines and not derived @<file>s were edited, the > latter means you need hosting on a server somewhere. Both require a > lot of dev. time. > > 3) Leo using a DB as a storage mechanism. This really has to be for > some reason, presumably to enable other items in this list. Not sure > if there's a performance boost here without lazy loading, which is a > big implementation issue, particularly for searches etc. Also, unless > you read the whole outline from the DB at once, I'm not sure about > performance on hierarchical data like Leo's. Postgresql supports > `WITH RECURSIVE` which could fetch subtrees in one request, not sure > about other DBs. Maybe not a problem with non-sql DBs. > > 4) Simultaneous / collaborative outline editing by multiple users. > This is where implementation gets hard unless there are APIs (Google?) > out there we can use off the shelf. Real-time simultaneous is > particularly challenging, but even reconciling edits by others > intermittently is tricky when you have issues like subtrees being > moved around the outline etc. > > 5) Versioned Leo nodes. This can be done independently of (4), it > would be quite easy to support node-local node histories in either > sqlite or git. Git offers the possibility of being an alternative to > a DB backend for (4), seeing it's probably not that hard to get free > hosting for git repos, easier than DB hosting maybe. A bit more > thought needed on the DB schema, I guess both nodes (headline, body, > *and* unknownAttributes) and links would need to be versioned. > Version identity would need to be some combination of time and user id > (a gnx? :-) > > I think it would be interesting to experiment with some mixture of > 3/4/5, in a code something and see what happens way. Keep it simple by > starting with user initiated import/export events instead of trying to > completely replace the load/save process, and perhaps ignore @<file>s > at first - in a way they're intrinsically tied to local resources. > > Perhaps a first step is to define a DB/DVCS adapter layer, which can > fetch and store nodes and links to/from some backend. > What should it return to Leo? A simple nested Python data structure I > guess, perhaps with the option to build it into a subtree at a > specified location. Can we use gnx's everywhere as node / link IDs for > these transactions? > > Cheers -Terry > > > Another topic is best workflow practices. Kent and I are interested in > > looking over Terry's shoulder for awhile :-) > > > > I would also like to discuss data base ideas. > > > > > 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. > > > > I agree. It's impressive. > > > > > 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> > > > > CoffeeScript, http://coffeescript.org/, is the proper way to program in > > JavaScript. It should not cause any brains to explode. Importantly, > there > > are tools that will convert JavaScript to CoffeeScript. I would want to > do > > this conversion before studying existing code. > > > > Having said this, programming directly in CoffeeScript looks like an > > "heroic" approach. Checkvist proves that such an approach is possible. > > Perhaps someone could convert Checkvist to CoffeeScript automatically, > and > > then relatively easily move on to Leo. But unless somebody in the Leo > > community actually has a *lot* of time on their hands, basing a project > on > > CoffeeScript isn't likely to make much headway. > > > > This leaves us with the question of in-browser frameworks. I haven't > paid > > any attention to this important topic. I imagine that there has been > > continuous incremental (or revolutionary) progress since last we looked > > around. I would like to explore the possibilities at the Leo sprint. > > > > These are just my thoughts. Feel free to suggest new ideas here, or to > > bring up new topics at the sprint. There won't be any formal agenda. > > > > Edward > > > > -- > 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.
