5 ms·

I would only object to that part of the article, as over-inflated: The 3270 hardware also came equipped, as standard, with the ability to "physically" update a

I would only object to that part of the article, as over-inflated: The 3270 hardware also came equipped, as standard, with the ability to "physically" update a small section of the remote screen buffer (including its text colour, background, input behaviour and other attributes) using a "Write" (modified) command, instead of needing to retransmit the entire screen buffer on every change (anticipating Ajax software technology that re-emerged some 22 years later for web 2.0 based applications and now utilized for online spreadsheets and most other recent applications for similar reasons). Claiming that the 3270 anticipated Ajax is really, shall I say, "interesting". I implemented a multi-user chat (similar to Linux talk) on a 3270, so I do appreciate the addressable location feature.

eudox 10y ago
Right. ncurses, too, implements the same kind of lazy redrawing of screen contents, and probably all graphics systems do this as well. The technique is fairy old.
- derefr 10y ago
  Forms in the 3270 protocol go a bit beyond lazy redrawing; AJAX is a (semi-)valid comparison. Effectively, when you "submit" a screen on a 3270, what you're sending back over the connection (before any optimizations) is the same block of characters you were originally sent to render the screen—but with your modifications, appearing exactly in the places you made them. The "addressable locations" allow for both reading and writing—as in, both sending updates from the server to the client (ncurses-like), and the client to the server (AJAX-like "onblur" submission of individual form fields.) Effectively, the client and server are both keeping a representation of the same terminal character-bufer (like screen(1) or VNC), but instead of sending updates whenever either side changes, updates are explicit. And so most 3270 server software uses the "the client synchronized the buffer to the server" event as the trigger for parsing, validating and persisting the data out of the buffer. When put that way, it's more like some kind of... REpresentational State Transfer, isn't it?

eudox 10y ago

Right. ncurses, too, implements the same kind of lazy redrawing of screen contents, and probably all graphics systems do this as well. The technique is fairy old.

derefr 10y ago
Forms in the 3270 protocol go a bit beyond lazy redrawing; AJAX is a (semi-)valid comparison. Effectively, when you "submit" a screen on a 3270, what you're sending back over the connection (before any optimizations) is the same block of characters you were originally sent to render the screen—but with your modifications, appearing exactly in the places you made them. The "addressable locations" allow for both reading and writing—as in, both sending updates from the server to the client (ncurses-like), and the client to the server (AJAX-like "onblur" submission of individual form fields.) Effectively, the client and server are both keeping a representation of the same terminal character-bufer (like screen(1) or VNC), but instead of sending updates whenever either side changes, updates are explicit. And so most 3270 server software uses the "the client synchronized the buffer to the server" event as the trigger for parsing, validating and persisting the data out of the buffer. When put that way, it's more like some kind of... REpresentational State Transfer, isn't it?