On Wed, Nov 10, 2010 at 01:41:36PM -0800, George Nachman wrote: > >> 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.
Hmmm. I'm not sure I'm really getting what you want to do. Do you really mean "session" here or do you mean "window"? If you mean session, then it may not be too difficult. tmux will still manage everything within the session, all you want is a way for it to pretend that multiple clients are attached on one stream (pair of file descriptors, whatever). We can extend the existing command set enough for you to get initial state and whatever else is missing. If you mean window, it sounds pretty much like writing a new UI for tmux which seems awfully ambitious. tmux can be thought of as MVC in many ways but there are some parts which fundamentally are not and decoupling things far enough to replace the UI would be a fairly big job... What exactly do you see your program doing and not doing? > > > >> 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. > I don't think we need to worry about escaping anything. ssh provides a way to make the connection fully transparent and we should just rely on future protocols doing so too, because it makes sense for them to. > > >> 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? No rewrapping. They are hidden at the new window edge until its made bigger again. > > 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, This is not difficult. > though. Of course it'd need to be sent over the framing protocol > discussed above rather than written to a file. ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
