In-Browser Leo

[David McNab]

Hi folks,

My latest job has been dragging me, (sometimes) kicking and screaming, up the steep learning curve of the venerated Ember.js framework.

This means that I could at some point soon be in a position to start tinkering with an in-browser application, with a very Leo-like front end, together with a back-end API and server app which updates a stored .leo file and its generated files.

This of course raises numerous issues of concurrency and conflict management, on which I'd be keen for some discussion.

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.

Cheers

David

[Terry Brown]

On Mon, 13 Oct 2014 06:38:48 +1300
David McNab <davidm...@gmail.com> 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

[David McNab]

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

--
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+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

[Kent Tenney]

It would be wonderful to need only a browser to Leo-edit my files
from anywhere, a real breakthrough.

While collaborative editing might eventually want to address concurrent
editing, sharing access to the files, (with file level locking) seems like
it go a _long_ way towards the goal of communal Leo.

[Edward K. Ream]

On Mon, Oct 13, 2014 at 5:44 AM, Kent Tenney <kte...@gmail.com> wrote:
> It would be wonderful to need only a browser to Leo-edit my files
> from anywhere, a real breakthrough.

I agree. This is more important than collaborative editing, which can
be saved for later, or never.

Edward

[Kent Tenney]

It would only require permissions for In-browser-Leo to
enable collaborative editing at the level of:
"I'll type in this url and open the Leo file that Edward just mentioned"

which would presumably be read-only.
or not:
"I'll add a comment to this node in said file"

both of those seem to be core capability, as opposed to:
"I'll make changes to this file while Edward is making changes to this file"

Which is not only technically challenging, but of dubious utility.

[Edward K. Ream]

On Mon, Oct 13, 2014 at 6:16 AM, Kent Tenney <kte...@gmail.com> wrote:
> It would only require permissions for In-browser-Leo to
> enable collaborative editing at the level of:
> "I'll type in this url and open the Leo file that Edward just mentioned"
>
> which would presumably be read-only.
> or not:
> "I'll add a comment to this node in said file"

Good point.

> both of those seem to be core capability, as opposed to:
> "I'll make changes to this file while Edward is making changes to this file"
>
> Which is not only technically challenging, but of dubious utility.

I agree. The basic capability you mention would indeed be a breakthrough.

Edward

[Terry Brown]

On Mon, 13 Oct 2014 08:59:41 -0500

"Edward K. Ream" <edre...@gmail.com> wrote:

So what do people see when they go here
http://moth.nrri.umn.edu:6080/vnc.html?host=moth.nrri.umn.edu&port=6080
password leouser?

Cheers -Terry

[Fidel N]

wow its great, isnt that what everyone is talking about? Is it easy to setup?

[Terry Brown]

For those who didn't get to try it, the link was to an in-browser
remote desktop session running Leo with its regular PyQt interface.
It's gone now, too big a hole to leave open very long.

On Mon, 13 Oct 2014 17:23:19 +0200
Fidel N <fidel...@gmail.com> wrote:

> wow its great, isnt that what everyone is talking about?

Not exactly, it's basically a remote desktop session which can be
accessed from a browser, with Leo running in the session.

My thought is that if you have a server which can run leoBridge, it may
also be able to run a virtual desktop with the Qt gui as well.

I guess the assumption is that leoBridge will run headless with minimal
python libraries, so it could be run on a range of web accessible
computers, and the javascript interface is needed to interact with it,
and in general I'd say that's true.

The assumption is that running leoBridge is a lower bar than running
PyQt and a virtual desktop of some kind, and that's probably true,
although I feel I'm now doomed to spend time trying to get this to run
on my Raspberry PI http://www.raspberrypi.org/ :-)

> Is it easy to setup?

Yes, I created a user on an Ubuntu machine, to get a default set of
limited rights, including not having access to my personal files...
which I realize isn't the case... plug pulled :-}

Anyway, I then had that user run a vncserver instance, which is not
really a virtual machine as such,
http://en.wikipedia.org/wiki/Virtual_Network_Computing the word virtual
is a misnomer here. And run Leo on the desktop of the vncserver.

Then I set up https://github.com/kanaka/noVNC to provide web access,
using the ``./utils/launch.sh --vnc localhost:5901`` proxy for access
to the vncserver.

Anyway, it was just an experiment - if you have a web attached server
which can run vnc and PyQt, you can use full Leo online anyway, but the
javascript interface is needed for cases where your server can only run
leoBridge.

Although I think it's untested, the assumption would be that the basic
Python environment available in many hosted servers could run leoBridge.

Cheers -Terry