>> 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.
I think this is the right way to go as it would give users the most flexibility. I don't want them to have to install tmux on their Macs if they're just using iTerm2 to connect to a linux host, for example. The user would do: localhost% ssh foo foo% tmux --somenewflag <user selects a menu option in iTerm2> At this point iTerm2 would begin communicating with tmux over the existing ssh session, downloading relevant state (list of sessions the tmux server knows about, screen contents for each one, perhaps some of the scrollback for each, etc.). iTerm2 would open native GUI tabs with each corresponding to a separate session living in the tmux server, all multiplexed through the single connection. >> 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? Sorry, was going too fast. I meant a protocol on top of whatever transport is available: could be ssh, a local pty, telnet, or something not yet invented. Because it should work over as many transports as possible, the framing protocol would need to be paranoid about escaping characters that could be used for inband signaling like nul, ^], tilde, etc., but perhaps with an option to be more relaxed in certain situations, like a local pty, for better performance. >> 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. How does tmux handle window resizing (i.e.,, SIGWINCH)? Does it re-wrap lines that are too long to fit? Truncate? >From the second email: > As far as history goes it would be possible for tmux to draw the entire > history to a file (or more accurately to a tmux buffer which could then > be saved to a file) as escape sequences for one terminal or another (we > already need an extension of capture-pane to save the history and there > is no reason it couldn't produce escape sequences). We want to get just a suffix of the history because it could be way too big to get "everything". Ideally we'd be able to grab the last N lines (for N on the order of 1000), but be able to request blocks going farther back if needed. I could live without the second part, though. Of course it'd need to be sent over the framing protocol discussed above rather than written to a file. ------------------------------------------------------------------------------ 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
