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.
