How Queen Works
If you haven't already, read the README get an overview and examples of the concepts used in this page.
Queen is intended to act as a browser pool. In real use, you should have one Queen server with many browsers connected to it.
- Queen Server A server which captures browsers ("Worker Providers"), which also has a TCP server to accept connections from Queen Remote applications. The Queen Server's role is to create workforces from connected worker providers.
- Worker Provider An application running in a browser capable of creating workers.
- Worker An iframe running a list of scripts with a socket object in it's context, allowing it to communicate with a server-side entity.
- Workforce A collection of workers.
- Queen Remote A thin-client, queen-remote allowing you to execute scripts on browsers connected to a Queen Server.
A Queen client is an application running in the context of a browser window. It's responsible for providing "workers" when asked for by the Queen server it is connected to, this is why it's referred to as a "worker provider" in the technical documentation. A worker is an iframe which loads a given list of scripts and can then communicate with a server-side entity through a socket object in the context of the iframe.
A Queen server is a HTTP server which client's connect to. It's responsible for facilitating the running of scripts on client-side workers. When the Queen is given a set of scripts, it creates a "workforce", a collection of client-side workers running a given script. The workforce can then be used to interact with the workers in a bi-directional manner.