Where does the functionality of selenium to control the browser lies in? - selenium

Question

Where does the functionality of the Selenium lie?
I've read somewhere that the language binding or API provides glue code to use Selenium in java.
Glue code or Binding code: The code that connects incompatible software components.
Jason Huggings wrote JavaScriptTestRunner to control the browser. The functionality to control the browser lie in the JavaScriptTestRunner.
It suffers from Same-origin policy. Paul Hammant created HTTP Proxy to bypass the Same-origin policy. This opened the doors to write tests in multiple languages. We are provided with an API to write tests.
Then WebDriver is created. WebDriver and RC are merged to form Selenium 2.
Where does the functionality to control the browser gone to?
Within the API?
Within the browser driver?
Why does the API is called as glue code or binding code? What does it bind?

Answer 1

Selenium in the general usage of the term is a library - a collection of code organized in modules and packages. In this form it's a WebDriver client - it can communicate with that kind of server, following the WebDriver protocol; thus enabling a programmer to control a browser.
Where does the functionality to control the browser gone to?
In the WebDriver protocol, and the server that translates the WebDriver commands to browser instructions, and back.
Selenium being a client gives you the ability to use this functionality, in your chosen language - conveniently, without you having to learn or directly run WebDriver requests and parse their response.
Why does the API is called as glue code or binding code? What does it bind?
In programming binding is the uniform / or well-defined API of a library, that connects lower-level code (other programs, or the OS) or protocols - WebDriver in this case, to higher-level concepts - your code. Wikipedia to the rescue, with more details.

Answer 2

Glue Code
Glue Code is the executable code most often the source code that serves the purpose of adapting different parts of code that would otherwise be incompatible. Glue code does not contribute any functionality towards meeting any program requirements as such. Instead, it often appears in code that lets the existing libraries or programs to interoperate among themselves, as in language bindings or foreign function interfaces. Glue code may be written in the same language as the code it is gluing together, or in a separate glue language. Glue code is very efficient in rapid prototyping environments where several components are quickly put together into a single language or framework.
JavaScriptTestRunner
Jason Huggins while testing an internal application at ThoughtWorks reduced the time which was required to manually step through the same tests with every change he made developing a Javascript library that could drive the interactions with the webpage which allowed him to automatically rerun tests against multiple browsers. He named this program as the JavaScriptTestRunner. Later, he made JavaScriptTestRunner open source. This library eventually became Selenium Core which underlies all the functionality of Selenium Remote Control (RC) and Selenium IDE.
Unfortunately, to work within the Same Origin Policy, Selenium Core must be placed in the same origin as the Application Under Test (AUT). So another ThoughtWork engineer, Paul Hammant, created a server that would act as an HTTP proxy masking the AUT under a fictional URL, embedding Selenium Core and the set of tests and delivering them as if they were coming from the same origin. This system became known as the Selenium Remote Control (Selenium RC), or Selenium 1.
Why to use HTTP proxy
Again, when web frameworks were becoming more complex and powerful, the restrictions of Web Browsers’ sandboxed Javascript environment were increasingly limiting the effectiveness of Selenium Core. Simon wanted a testing tool that spoke directly to the browser using the "native" method for the browser and operating system, thus avoiding the restrictions of a sandboxed Javascript environment. That was when WebDriver and Selenium RC were merged to form Selenium 2. All implementations of WebDriver that communicate with web browsers started using a common wire protocol. This wire protocol defined the RESTful web service using JSON over HTTP.
Conclusion
In short, the functionality to control the browser was always within the Javascript library that driven the interactions with the webpage which was part of the JavaScriptTestRunner and later Selenium Core.
As per the diagram below with respect to the different classes/interfaces the functionality to control the browser is with the selenium-api