search

ChrisPenner / rasa

Extremely modular text editor built in Haskell
GNU General Public License v3.0
616 stars 42 forks source link

Remote UI protocol #42

Open DarwinSenior opened 7 years ago

DarwinSenior commented 7 years ago

In regards to remote UI protocal #8 @ChrisPenner, I have a proposal of the following. Currently it is just the update part of the communication, there should also be another part about how to handling event.

I am not quite good at Haskell and, and it seems that if we standardized the protocol, it does not have to be for remote UI. I am not quite good at Haskell and I appreciate any suggestions.

I put my proposal into a gist. Any comments are welcome.

DarwinSenior commented 7 years ago

Two things, we could always use JSON protocol instead of msgpack since they are identical but one with additional encoding (and seems to support streaming). And it does not necessarily need to be the remote UI. It is possible to implement a TUI with this too.

DarwinSenior commented 7 years ago

The other thing I think is that is it wise to use the Action monad directly? Do we need to consider the possibility that there might be different contexts?

robinvd commented 7 years ago

One thing I really like about this is the possible server client architecture, like Emacs. I think this can all be implemented as an extension and no changes are needed in the core.

ChrisPenner commented 7 years ago

Okay! So the first thing I should point out are the challenges of doing something like this in Rasa vs Vim or Emacs or other editors. The biggest thing is that Rasa doesn't have a standardized UI; renderers are all extensions and can essentially do whatever they like with the data they're provided with. I'm okay with standardizing a thing or two; but I don't think we can comfortably say that every Rasa config will line up as having a single status bar or sidebar or whatever. You'll also note that Rasa-core doesn't even know about having Cursors haha! It may seem a bit crazy at first, but it's part of Rasa's vision to be as modular as possible.

I really appreciate the work you've put into the Proposal; we'll just need to tweak it a bit 😋

We may need to set up msgpack to simply send the buffer information and let the client-side decide what to do with it via extensions; OR we could have a base msgpack extension which accepts adapters for each renderer, and a renderer could implement their own extension for msgpack if they want to use it which sends info in the format they want; in Haskell this is relatively do-able using type-classes (kind of like interfaces in other languages like Go or Java).

Currently Slate is the de-facto renderer so it's a great place to start, but others will pop up over time.

Why don't you start by making a server which can send the text for Buffers when they're updated via BufTextChanged; I think that's a good place to get going on it! Ask any questions you need to as they come up!

robinvd commented 7 years ago

So looking at Data.MessagePack, that only handles the encoding? so the extension would still need a connection to a renderer