Hi,

It's good to see the advances in the servers direction. The idea of a
more decoupled Leo with web interfaces and the idea of "outlining"
services to other systems and languages that some have proposed seems close.

I would avoid going into the Apache path and I would try to choose a
minimalist pure python web framework (bottle, flask, other used by
Jupyter) that can deal with the server/sockets core code functionality
in Leo and leave the scaling part to a server neutral back-end (Apache,
Cherokee, Lighttpd, Enginx, etc.)

When I was trying to implement ideas from Leo in Pharo/Smalltak I
remember focusing on the "outlining experience" first. I wanted to be
able to add/remove and move nodes that have a "header" and a "body"
inside Pharo. Sometimes, when I think in this idea of "outlining"
services using a web interface I think which is the minimal web library
that provides me a tree interface, for example Inspire Tree[1], and how
I would connect it to the tree representation I already have in
Grafoscopio. Because I don't want to have a lot of moving parts in
different languages and programming paradigms (something that already
happens to Jupyter), I would like to create some socket/service that
connects the web interface with the Pharo backend. So all the machinery
behind trees is already there and the only "new thing" I'm implementing
is a way to decouple the GUI so it can be a web app.

[1] http://www.inspire-tree.com/

Hopefully, something like that can be the path for services/sockets in
Leo. I wonder how Leo-Vue can connect to Leo server, for example and
what is the demo MVP for a web interface that connect with a Leo backend.

Cheers,

Offray


On 10/21/18 5:46 AM, Edward K. Ream wrote:
> The biggest roadblock of my career has disappeared. At last I see that:
>
>    *Sockets, not servers, are the basis of IPC (inter-process
> communication)
> *
>
> *   Servers exist because of sockets, not the other way around.
> *
>
> Getting this backward created no end of confusion. Everything seems
> clearer:
>
> - Connecting two processes means creating a socket between them.
>
> - Python's server (http.server in 3), asyncore and asynchat modules
> are just wrappers around sockets.
>
> - The request/response and publish/subscribe messaging patterns are
> two ways of using sockets. 
>
> - A server is required for /every /socket that uses the
> request/response pattern.
>
> - curl creates traffic on a socket, which a server then may handle, or
> not.
>
> *History*
>
> 1. All this became clear sometime between Friday morning and Saturday
> night, but I do not remember exactly when! It probably happened while
> talking to my brother Speed Friday afternoon.  I took these notes
> during that conversation:
>
> - Sockets are about IPC that "just works".  Pipes and shared memory
> are alternatives on a single machine, but sockets are essential for
> the internet.
>
> - Sockets are protocol agnostic. Sockets can use any protocol,
> including custom protocols.
>
> - The internet is a network of socket servers.  If I had to guess, it
> was this statement that triggered the Ahas. I immediately told Speed
> that this statement changed my understanding of the internet.
>
> 2. Yesterday morning I created my first socket using Python 3, created
> a small Python server based on this python 2 code
> <https://gist.github.com/bradmontgomery/2219997>, and used curl to
> test that server. That was the first time I ever used curl.
>
> 3.  Yesterday afternoon I talked with Speed again, discussing the Ahas
> in detail. I am fairly confident that I have the big picture right.
>
> 4. We then discussed Leo as a web app. Speed suggested that we avoid
> doing things twice. Python servers have their limitations, so
> eventually we will want to use a server like Apache.  That being so, I
> may as well start using Apache now.  That eliminates duplicating
> server configuration work.
>
> *Summary*
>
> Sockets, not servers, are the foundation almost all IPC, including the
> internet. This page
> <https://docs.oracle.com/javase/tutorial/networking/sockets/definition.html>
> is a clear introduction to sockets.
>
> Focusing on sockets ended massive confusion about clients and servers.
>
> All internet software, including curl, handles traffic on sockets.
>
> Leo as a web app will use a server that responds to events in the
> browser. The socket protocol will likely be a private protocol rather
> than http. The server will be something like Apache, not a python server.
>
> All my old fears of internet-related technology are gone. Many thanks
> to Speed for his patient help. I eagerly look forward to lots of study.
>
> All comments, suggestions for further study, and (especially!)
> corrections are welcome. 
>
> 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]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at https://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 https://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.

Reply via email to