Hello everybody ! I'll chime in I guess ;)
Thank to everyone commenting and giving ideas and suggestions! That's how most of the features were born! I'll make sure to revise the documentation before committing all the changes I'm making. I'm still working on the new leoserver.py that Edward started (based on the old/original leobridgeserver.py) but with better global/class/methods hierarchy /encapsulation and architecture. (Thanks to Edward !) To address Viktor's last point: Both the original, and the new one, *are made to be totally agnostic of the client and are not made with leointeg exclusivity in mind at all.* Any signs of that not being the case are/were accidental, and are being corrected. (it's true that sometimes the nomenclature of some json object members matched vscode terminology instead of Leo's. For example, in Leo we refer to the current cursor locations as the cursor 'insert' point. not the 'active' point like in vscode. This was accidental and not intended) So yes, it may have been created at first to support leointeg, but it exists to support any and all other web-socket GUI client that may (or will) exist. And that's why Edward and I think it should be part of Leo-Editor and not leointeg. So I'll keep working in this server cleanup & tune up for a couple more days : As soon as I'm done with this I'll commit it and push it to the leo-editor repo. (I'll also modify the client.py to match the modifications and run the tests that goes with it) In the meantime, if you're curious, you can checkout the issue130 branch of leointeg and open the leo file to see the last node is a backup of my progress with the leoserver.py's main class, and matching changes to the old leobridgeserver.py . (I would have done this on a 'felix-server' branch of the leo-editor repo but their was a problem with the devel branch a few days ago and i just kept adding to my issue1130 branch of leointeg instead to keep an online backup for safety) Oh - and i'm totally down to provide a 'http get/post' mode also if people are interested. ...the very first versions of the server didn't use websockets nor http, it was just using command line process pipes in/out. so minimal work should provide other ways of communication if needed. :) -- Félix On Saturday, May 15, 2021 at 3:14:04 PM UTC-4 [email protected] wrote: > Hello Edward, > > Edward K. Ream schrieb am Samstag, 15. Mai 2021 um 17:51:53 UTC+2: > >> On Sat, May 15, 2021 at 8:06 AM [email protected] <[email protected]> >> wrote: >> >>> I'm not necessarily saying that it doesn't do what it's supposed to. >>> I'm saying that the draft doc doesn't say what it is supposed to do, at >>> least not so an inexperienced user can do anything with it. >> >> >> At present (I've just pushed some changes to the ekr-docs branch), the >> first two sentences of the new chapter are: >> > QQQ >> >> leoserver.py is a stand-alone web **socket** server that provides access >> to Leo’s capabilities using Leo’s bridge. >> > leoserver.py exists to support leoInteg: Leo hosted on Visual Studio Code. >> >> QQQ >> >> leoserver.py is not for inexperienced users. Imo, the above description >> does describe what the server does, and is supposed to do :-) >> > > This describes the current state of the Leo Server work a lot better than > the initial version. > > It does make it clear, that its focus at the moment is to support leoInteg > - and - is not intended to address any other use cases yet ... > > With kind regards, > > Viktor > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/9aff1348-862f-4f0f-8e71-f9f4463b26adn%40googlegroups.com.
