On 10 February 2016, Bram Moolenaar <b...@moolenaar.net> wrote:
>
> Lcd wrote:
>
[...]
> > I'm afraid I still don't get it. With jobs Vim can communicate
> > with processes that aren't specifically aware they are talking
> > to Vim. It can do that by opening pipes for the jobs' stdin and
> > stdout. If it needs to give them "wheels" (that is, communicate
> > with processes on another machine), this can be done with UCSPI.
> > This is a solved problem, and the common solutions such as UCSPI can
> > do things like connect over TLS (and actually get it right), and do
> > fancy TCP window scaling and error recovery.
> >
> > On the other hand, there are daemons that do things like parse a
> > source tree in background and can be queried about it over a socket.
> > But these daemons have their own APIs, and are not specifically
> > prepared to talk to Vim. Making Vim able to talk to them would
> > require some kind of adapter, which might be a job started by Vim.
> > But then the burden of handling protocols, TCP, and so on would be
> > on the adapter. Vim could still talk to the adapter through pipes
> > to the adapter's stdin and stdout. But the adapter would have to
> > be written specifically for the particular daemon, and there's no
> > way around that. If Vim is to talk directly to the daemon, without
> > the adapter, then JSON or protocol buffers are either too much, or
> > too little. I can't see how channels (as they are now) can fit into
> > this picture. _shrug_
>
> It seems you are missing that stdin/stdout IS the channel. On top of
> it you can define the protocol: raw, NL-separated, JSON, etc.
Yes, channels are supposed to provide a library of protocols and
codecs, I (think I) understand that.
> So if that deamon speaks language X, then you connect with a raw
> channel and let the Vim plugin decode language X. Hopefully you can
> do something more clever (raw messages suffer from the problem that
> you never know when the message ends).
>
> It's the good old layering: lower layer about how to connect and
> send/receive (socket, pipe, whatever), layer above that about the
> contents (message separation and parsing). Even higher about what
> request belongs to what response (what is currently only supported for
> JSON, using sequence numbers).
My point is Vim shouldn't try to handle the lowest layer in this
model. Protocol decoding is often the least problem in using an API.
Consider f.i. authentication: I presume nobody in his right mind is
going to write an OAuth 2.0 handler in VimL. So authentication has
to be delegated to a lower level daemon anyway, the thing I called
"adapter" above. Well, this adapter is likely to be a script written
in Python, or Perl, or Ruby, or some such. The interpreters for these
languages are a lot faster than Vim can hope to be, and they already
have plenty of libraries for all protocols, codecs, and everything else
remotely useful for dealing with any API. It's much easier to handle
all these details in an external script, and translate the results to a
minimal interface for Vim.
[...]
> >
> > I don't think a job's input can be allowed access to Vim's tty,
> > ever.
>
> Unless it's a filter. Or a job that needs to prompt the user. It's
> tricky though, as soon as two processes read from the tty things go
> haywire. But as you mention above, using existing commands that
> weren't specifically made to be used by Vim this way, it may be the
> only way to make it work. I expect that the thing we might need to
> support is a job prompting for something only right at the start.
> E.g. to enter a password. Imagine connecting to a server to access a
> database. Better would be if the plugin can prompt the user before
> starting the job, but that might not always work.
Interactive programs shouldn't run in background to begin with.
Things like passwords can usually be passed in environment variables, on
the command line, or in special files. But "true" interactive prompts
really complicate the problem exponentially.
> > There are two main cases here: programs that don't need any input,
> > and are happy with command line options; and programs that need to
> > read things from stdin. In the first case there's no problem to
> > solve. It's the second case that's interesting, and there Vim could
> > either use another callback for the job's stdin to feed it data as
> > the job requests, or simply let it read from a file. The callback
> > is problematic, because it can run into deadlocks with the callbacks
> > for output (this is a well-known hard problem). Reading from a file
> > is safe, but limits what the job can do.
>
> Right. We'll probably need to see a practical example. We can have
> an input handler, but asynchronously prompting the user for input, a
> dialog that pops up, is a completely new concept. For now I think we
> can omit it.
Vim is still a text editor. :) Being able to run in background
programs that don't care about stdin would be a huge step ahead already.
/lcd
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
