On Sat, Nov 06, 2010 at 05:05:31PM -0700, George Nachman wrote: > > There are three approaches I can see: > > > > 1) Protocol changes. This could work, could have a flag to mark this as > > an "extended" client that gets additional update messages in various > > places. I'd be concerned how invasive this would be though. > > Now that I understand your architecture better, it's pretty clear to > me that we don't want to write our own client. I want to support the > use case of ssh'ing to a remote host and running the tmux client > there.
In that case your only options from what I can see are: a) Open an ssh each time to run tmux commands. b) Add the ability to tmux to sit with stdin and stdout open permanantly, accepting commands and return responses (think UW popd/imapd). c) Parse/manipulate existing tmux output over ssh. > > > 2) Call tmux commands through the existing client. There is at least one > > project I know of that does this already to provide a Ruby API to > > tmux. > > I found the project (tmux-ruby) but not any documentation for it, so > it's hard to tell at a glance if it's the right direction. I suspect > we want more semantic understanding of the responses than they do, > though. > > > You'd have to poll if you wanted to update your state, and probably > > would need some additional commands (eg there is no way to grab the > > history at the moment), but those would be easy to add and would have > > the side-effect of improving the client interface for everyone. > > It seems like we would need a framing protocol on top of TCP to talk > to each other so we could receive new data from the tty while making > and responding to RPCs asynchronously. I think we could live with > polling but it's not ideal, as we'd have to poll pretty frequently to > appear interactive and people would complain about the bandwidth > usage. I don't get where TCP comes in here. Do you mean you'll need a protocol on top of ssh? > > > At the moment a lot of the output from tmux is a bit ad hoc and would > > benefit from a close look for completeness and how easy it is to parse > > and once it is done it isn't likely to change much. > > > > It would be trivial to add simple things (menus of sessions/windows, > > option to copy tmux paste buffer to your own etc) with this but for > > complex things I don't know. > > Does tmux keep its own concept of the screen contents, with metadata > for each character about color, blink, etc.? I have a feeling managing > the scrollback buffer will be the biggest challenge here. Yes it has to keep an entire separate view of each pane and its history. > > > 3) Act as a client and call tmux commands with MSG_COMMAND. Once > > attached, responses go to the terminal not back to the client so back to > > option (1)... You could maybe open two clients, one to attach and one to > > send commands/get responses but that seems like a hack. > > > > This won't work for the same reason I gave for #1. ------------------------------------------------------------------------------ The Next 800 Companies to Lead America's Growth: New Video Whitepaper David G. Thomson, author of the best-selling book "Blueprint to a Billion" shares his insights and actions to help propel your business during the next growth cycle. Listen Now! http://p.sf.net/sfu/SAP-dev2dev _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
