I had thoughts of this for some years, but it's only now as I'm coming up to speed with Ember, and grasping some of the tremendous leverage it offers, that I am seriously considering an in-browser front end.
My naive view of a node is that of having a main set of properties: - Text content (including Leo markups such as @something and <<something>> - Ordered sequence of references to child nodes In collaborative editing, a 'lock' on a node would ideally lock all its descendants. This lends itself to the idea of User A wanting to edit a node that User B has locked, being able to trigger a 'please unlock this node' request to User B, which cause the node on User B's screen to flash or show in a different colour. For the back-end, a python-based server would be the ideal choice. With apologies to node.js enthusiasts, I personally don't believe javascript has any place on a server, except for building the file set that gets served to the client. So from here, it's just a matter of thinking up a suitable conflict-management protocol, designing an API, wiring it in to LeoBridge.py, and finding some good widgets to bolt together on the front end. I feel it's important we think about things like this, especially now that the days of the traditional native desktop application are looking more and more numbered. Cheers David On Mon, Oct 13, 2014 at 9:03 AM, 'Terry Brown' via leo-editor < [email protected]> wrote: > On Mon, 13 Oct 2014 06:38:48 +1300 > David McNab <[email protected]> wrote: > > > One thought I've had is for the web app to have all nodes, by default, > > flagged as read-only. If wanting to edit a node's contents, a hot-key > > sends a 'lock request' to the server, gets an "ok" or "not ok" > > response. If ok, then the user can then start editing the node, until > > s/he 'saves' the node, which then releases the lock. > > > > The concept of a 'lock' would mean the exclusive ability to edit a > > node's existence, contents and child nodes. > > > > Any thoughts? Forgive me if it's been discussed n times before. > > I don't think it's been discussed at this level of detail before. I > started something along these lines, jQuery and maybe CoffeeScript, > can't remember, but it's stalled and I haven't touched it for a while. > It used leoBridge.py as the Leo backend, really just trying to get > collaborative editing of trees working, although single user would be > very useful too. A model that required a server running Python though, > not sure if that's what you're thinking, vs. pure js. > > Anyway, to the specific question of node locking, I think what you > suggest would work fine for individual nodes. The tricky part to make > collaborative is moving parts of the tree around, although I imagine > this has been solved before somewhere. I guess locking the node and > all its parents would be an option. > > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/leo-editor. > For more options, visit https://groups.google.com/d/optout. > -- 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. For more options, visit https://groups.google.com/d/optout.
