Confirmed users
3,816
edits
Auto-tools/Projects/JSON Protocol Testing: Difference between revisions
Auto-tools/Projects/JSON Protocol Testing (view source)
Revision as of 16:44, 14 September 2011
, 14 September 2011no edit summary
(Created page with "= The Problem = The paradigm of our entire automation solution works on a very simple concept. Here's the concept: 1. We create a profile of our making 2. We start the browser in...") |
No edit summary |
||
| Line 9: | Line 9: | ||
There are a few options for doing this. | There are a few options for doing this. | ||
Approach 1: "Bazooka" aka JsBridge | = Approach 1: "Bazooka" aka JsBridge = | ||
JsBridge is a tool from the mozmill tool chain that creates a listening socket inside of the product. By communicating to this socket, you can send in raw javascript and have it executed in a browser context. It's essentially RPC for javascript. | JsBridge is a tool from the mozmill tool chain that creates a listening socket inside of the product. By communicating to this socket, you can send in raw javascript and have it executed in a browser context. It's essentially RPC for javascript. | ||
| Line 15: | Line 15: | ||
Downside: The API isn't that good, and isn't really going to be an amenable solution to platform developers. It's not something I think we can actually upstream into the Gecko platform. | Downside: The API isn't that good, and isn't really going to be an amenable solution to platform developers. It's not something I think we can actually upstream into the Gecko platform. | ||
Approach 2: "Four tons" aka webdriver | = Approach 2: "Four tons" aka webdriver = | ||
Webdriver works through a HTTP REST interface. They have a well-defined API for interacting with a UI system (content only right now, no reason it can't be amended to work with chrome as well) and for running random scripts in the browser context. The current webdriver idea is to embed our old friend httpd.js into the browser to provide the HTTP interface for the protocol. This takes too much memory on fennec and doesn't work. | Webdriver works through a HTTP REST interface. They have a well-defined API for interacting with a UI system (content only right now, no reason it can't be amended to work with chrome as well) and for running random scripts in the browser context. The current webdriver idea is to embed our old friend httpd.js into the browser to provide the HTTP interface for the protocol. This takes too much memory on fennec and doesn't work. | ||
| Line 22: | Line 22: | ||
Downside: It's '''heavy'''. The API requires keep-alives, proper HTTP Responses, needs to accept and parse HTTP POST & Get requests etc. It's not clean, it's not simple, and it's a bit unwieldy to work with. We already know that as-is it won't work in a mobile environment. So, we have to try to cut away pieces of the HTTP server and hope we don't break anything in the process, and that means further forking of an already forked (the webdriver project not only reused httpd.js, they forked it too) httpd.js. | Downside: It's '''heavy'''. The API requires keep-alives, proper HTTP Responses, needs to accept and parse HTTP POST & Get requests etc. It's not clean, it's not simple, and it's a bit unwieldy to work with. We already know that as-is it won't work in a mobile environment. So, we have to try to cut away pieces of the HTTP server and hope we don't break anything in the process, and that means further forking of an already forked (the webdriver project not only reused httpd.js, they forked it too) httpd.js. | ||
Approach 3: "Surgical Strike" aka The Debugger Approach | = Approach 3: "Surgical Strike" aka The Debugger Approach = | ||
The JSD team has a remote javascript debugger interface that opens a socket inside the browser and accepts a JSON protocol over the socket. This is most like what we want, simple, lightweight, versatile. However, the remote debugger socket protocol is not readily extensible for us to use our own protocol over the socket, and it's not clear if we want to be in "debugging" mode to turn on our automation support. | The JSD team has a [http://hg.mozilla.org/users/dcamp_campd.org/remote-debug/file/f82ec43a9b04/toolkit/components/debugger remote javascript debugger] interface that opens a socket inside the browser and accepts a JSON protocol over the socket. This is most like what we want, simple, lightweight, versatile. However, the remote debugger socket protocol is not readily extensible for us to use our own protocol over the socket, and it's not clear if we want to be in "debugging" mode to turn on our automation support. | ||
Also, being able to run tests and debug at the same time is important. We don't want to prevent that usecase and it's not clear if we can multiplex JSON over the socket and not confuse the debugger code. However, adding an entirely separate socket system into the platform really seems like egregious overkill. We've got this one wired in now, we should reuse it. | Also, being able to run tests and debug at the same time is important. We don't want to prevent that usecase and it's not clear if we can multiplex JSON over the socket and not confuse the debugger code. However, adding an entirely separate socket system into the platform really seems like egregious overkill. We've got this one wired in now, we should reuse it. | ||