From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@cse.psu.edu Subject: RE: [9fans] file name completion From: Charles Forsyth In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Mon, 22 Dec 2003 11:38:59 +0000 Topicbox-Message-UUID: af0e91ea-eacc-11e9-9e20-41e7f4b1d025 > A nice exercise in its usefulness is the breaking down of a huge, monolithic program such > as Links into smaller parts tied together by plumbing -- from an all-encompassing piece of > code that knows how to handle everything from rendering html tables to handling ftp and > samba protocols, into a simple html renderer that works with the plumber to give out work > to whichever external program is best suited for the job (and not having to know anything > about them)... it would be nice if that were possible but it's the interaction between javascript and html rendering, at many and seemingly arbitrary points, that complicates browsers, even as regards interaction with the transport protocols (fortunately less so, so that those can indeed be handled in a more modular way). for instance, javascript has an interface to the state of the renderer. conversely, and perhaps even worse, the renderer implementation needs to provide the sort of state that the javascript interface expects, which further limits design and implementation freedom. actually, there are several interfaces because different browsers historically gave javascript access to state that their implementations happened to provide, which changed from browser to browser.