Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remote UI protocol #42

Open
DarwinSenior opened this issue Feb 9, 2017 · 5 comments
Open

Remote UI protocol #42

DarwinSenior opened this issue Feb 9, 2017 · 5 comments

Comments

@DarwinSenior
Copy link

DarwinSenior commented Feb 9, 2017

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
Copy link
Author

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
Copy link
Author

DarwinSenior commented Feb 9, 2017

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
Copy link
Contributor

robinvd commented Feb 9, 2017

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
Copy link
Owner

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
Copy link
Contributor

robinvd commented Feb 11, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants