Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-05-05T07:06:52Z

Wpgallih: /* Test Cases */

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
The requirements for the implementation is well detailed in the HTML spec shown here [https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

==Implementation==
The full implementation specs are outlined here: https://github.com/servo/servo/wiki/WebSocket-student-project

In general the websocket has 3 functions:
*Open() - Initiates and connects the websocket to the server. Once the connection is open, hands receives.
*Send() - Sends application data to the server
*Close() - Closes the websocket connection

In addition the websocket has the following attributes:
*readyState - indicates the current state of the websocket. The websocket can be in one of the five states below:
**Connecting - an initial connection handshake has been started but the server has not responded to the handshake yet
**Open - the connection has been established (server has responded to the initial connection handshake)
**Closing - an initial close connection handshake has been started but the server has not responded to the handshake yet
**Closed - the connection has been closed (server has acknowledged the closing handshake and responded)
*Extensions - Extensions are being used by the websocket (see full specs link above)
*Protocol - Protocols being used by the websocket (see full specs link above)
*bufferedAmount - returns how many bytes of application data has been buffered in the websocket thus far (unsent data)

==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Test Cases==

The test cases for WebSocket are already implemented and included in Servo. Servo uses a testing system which allows skipping of features not included, or passed. Therefore, when the WebSocket tests are included, it is not only necessary to know how to run them, it is important to be able to use the tools that automatically update the tests passed as well.

First, to include the websocket tests, add the following lines in the tests/wpt/include.ini file:
<code> 
[websockets] 
skip: false 
</code>

Then, you will need to run the tests, and update the test expectations from the results. To run the tests, do the following command:
<code> 
./mach test-wpt --log-raw /tmp/servo.log
</code>

The servo.log will be used to update the test expectations. Once the tests have finished, update the test expectations using the following command:
<code> 
./mach update-wpt /tmp/servo.log
</code>

Further reading on updating the test harness for Servo can be found here [http://mxr.mozilla.org/servo/source/tests/wpt/README.md#71]

In addition to the test cases provided by Servo, we included a test websocket page which used all of the expected interface for a websocket. This was more a design to interface, where each stage of including a function could be seen on progress on our test page. This test page came from her: [http://www.websocket.org/echo.html] and is stored in tests/html/test-websocket.html. To run this test, use the following command:
<code> 
./mach run tests/html/test-websocket.html
</code>

This code will open a websocket, print connected, send a message, then print a received message before closing. As stated before, this is more a test to interface tool, instead of testing the conformance to spec and robustness of the code created.

==Further Readings==
[https://html.spec.whatwg.org/multipage/comms.html#network HTML Spec for WebSockets] 
[https://github.com/servo/servo/wiki/WebSocket-student-project Mozilla Websocket Project Page] 
[https://github.com/servo/servo Servo github] 
[http://cyderize.github.io/rust-websocket/ Rust Websocket] 

==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-05-05T07:03:21Z

Wpgallih: /* Test Cases */

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
The requirements for the implementation is well detailed in the HTML spec shown here [https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

==Implementation==
The full implementation specs are outlined here: https://github.com/servo/servo/wiki/WebSocket-student-project

In general the websocket has 3 functions:
*Open() - Initiates and connects the websocket to the server. Once the connection is open, hands receives.
*Send() - Sends application data to the server
*Close() - Closes the websocket connection

In addition the websocket has the following attributes:
*readyState - indicates the current state of the websocket. The websocket can be in one of the five states below:
**Connecting - an initial connection handshake has been started but the server has not responded to the handshake yet
**Open - the connection has been established (server has responded to the initial connection handshake)
**Closing - an initial close connection handshake has been started but the server has not responded to the handshake yet
**Closed - the connection has been closed (server has acknowledged the closing handshake and responded)
*Extensions - Extensions are being used by the websocket (see full specs link above)
*Protocol - Protocols being used by the websocket (see full specs link above)
*bufferedAmount - returns how many bytes of application data has been buffered in the websocket thus far (unsent data)

==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Test Cases==

The test cases for WebSocket are already implemented and included in Servo. Servo uses a testing system which allows skipping of features not included, or passed. Therefore, when the WebSocket tests are included, it is not only necessary to know how to run them, it is important to be able to use the tools that automatically update the tests passed as well.

First, to include the websocket tests, add the following lines in the tests/wpt/include.ini file:
<code> 
[websockets] 
skip: false 
</code>

Then, you will need to run the tests, and update the test expectations from the results. To run the tests, do the following command:
<code> 
./mach test-wpt --log-raw /tmp/servo.log
</code>

The servo.log will be used to update the test expectations. Once the tests have finished, update the test expectations using the following command:
<code> 
./mach update-wpt /tmp/servo.log
</code>

Further reading on updating the test harness for Servo can be found here [http://mxr.mozilla.org/servo/source/tests/wpt/README.md#71]

In addition to the test cases provided by Servo, we included a test websocket page which used all of the expected interface for a websocket. This was more a design to interface, where each stage of including a function could be seen on progress on our test page. This test page came from her: [http://www.websocket.org/echo.html] and is stored in tests/html/test-websocket.html. To run this test, use the following command:
<code> 
./mach run tests/html/test-websocket.html
</code>

==Further Readings==
[https://html.spec.whatwg.org/multipage/comms.html#network HTML Spec for WebSockets] 
[https://github.com/servo/servo/wiki/WebSocket-student-project Mozilla Websocket Project Page] 
[https://github.com/servo/servo Servo github] 
[http://cyderize.github.io/rust-websocket/ Rust Websocket] 

==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-05-05T06:54:40Z

Wpgallih: /* Test Cases */

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
The requirements for the implementation is well detailed in the HTML spec shown here [https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

==Implementation==
The full implementation specs are outlined here: https://github.com/servo/servo/wiki/WebSocket-student-project

In general the websocket has 3 functions:
*Open() - Initiates and connects the websocket to the server. Once the connection is open, hands receives.
*Send() - Sends application data to the server
*Close() - Closes the websocket connection

In addition the websocket has the following attributes:
*readyState - indicates the current state of the websocket. The websocket can be in one of the five states below:
**Connecting - an initial connection handshake has been started but the server has not responded to the handshake yet
**Open - the connection has been established (server has responded to the initial connection handshake)
**Closing - an initial close connection handshake has been started but the server has not responded to the handshake yet
**Closed - the connection has been closed (server has acknowledged the closing handshake and responded)
*Extensions - Extensions are being used by the websocket (see full specs link above)
*Protocol - Protocols being used by the websocket (see full specs link above)
*bufferedAmount - returns how many bytes of application data has been buffered in the websocket thus far (unsent data)

==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Test Cases==

The test cases for WebSocket are already implemented and included in Servo. Servo uses a testing system which allows skipping of features not included, or passed. Therefore, when the WebSocket tests are included, it is not only necessary to know how to run them, it is important to be able to use the tools that automatically update the tests passed as well.

First, to include the websocket tests, add the following lines in the tests/wpt/include.ini file:
<code> 
[websockets] 
skip: false 
</code>

==Further Readings==
[https://html.spec.whatwg.org/multipage/comms.html#network HTML Spec for WebSockets] 
[https://github.com/servo/servo/wiki/WebSocket-student-project Mozilla Websocket Project Page] 
[https://github.com/servo/servo Servo github] 
[http://cyderize.github.io/rust-websocket/ Rust Websocket] 

==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-05-05T06:53:52Z

Wpgallih: /* Proposed Test Cases */

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
The requirements for the implementation is well detailed in the HTML spec shown here [https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

==Implementation==
The full implementation specs are outlined here: https://github.com/servo/servo/wiki/WebSocket-student-project

In general the websocket has 3 functions:
*Open() - Initiates and connects the websocket to the server. Once the connection is open, hands receives.
*Send() - Sends application data to the server
*Close() - Closes the websocket connection

In addition the websocket has the following attributes:
*readyState - indicates the current state of the websocket. The websocket can be in one of the five states below:
**Connecting - an initial connection handshake has been started but the server has not responded to the handshake yet
**Open - the connection has been established (server has responded to the initial connection handshake)
**Closing - an initial close connection handshake has been started but the server has not responded to the handshake yet
**Closed - the connection has been closed (server has acknowledged the closing handshake and responded)
*Extensions - Extensions are being used by the websocket (see full specs link above)
*Protocol - Protocols being used by the websocket (see full specs link above)
*bufferedAmount - returns how many bytes of application data has been buffered in the websocket thus far (unsent data)

==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Test Cases==

The test cases for WebSocket are already implemented and included in Servo. Servo uses a testing system which allows skipping of features not included, or passed. Therefore, when the WebSocket tests are included, it is not only necessary to know how to run them, it is important to be able to use the tools that automatically update the tests passed as well.

First, to include the websocket tests, add the following lines in the tests/wpt/include.ini file:
<code>
[websockets]
skip: false
</code>

==Further Readings==
[https://html.spec.whatwg.org/multipage/comms.html#network HTML Spec for WebSockets] 
[https://github.com/servo/servo/wiki/WebSocket-student-project Mozilla Websocket Project Page] 
[https://github.com/servo/servo Servo github] 
[http://cyderize.github.io/rust-websocket/ Rust Websocket] 

==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-04-02T01:56:30Z

Wpgallih: /* Further Readings */

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
The requirements for the implementation is well detailed in the HTML spec shown here [https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

==Implementation==
'''When the WebSocket connection is established, the user agent must queue a task to run these steps:'''
*If the WebSocket object's client-specified protocols was not an empty list, but the subprotocol in use is the null value, then fail the WebSocket connection, set the readyState attribute's value to CLOSING, and abort these steps.
*Change the readyState attribute's value to OPEN.
*Change the extensions attribute's value to the extensions in use, if is not the null value.
*Change the protocol attribute's value to the subprotocol in use, if is not the null value.
*Act as if the user agent had received a set-cookie-string consisting of the cookies set during the server's opening handshake, for the URL url given to the WebSocket() constructor.
*Fire a simple event named open at the WebSocket object.

'''When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps:'''
*If the readyState attribute's value is not OPEN, then abort these steps.
*Let event be a newly created trusted event that uses the MessageEvent interface, with the event type message, which does not bubble, is not cancelable, and has no default action.
*Initialise event's origin attribute to the Unicode serialisation of the origin of the URL that was passed to the WebSocket object's constructor.
*If type indicates that the data is Text, then initialise event's data attribute to data.
*If type indicates that the data is Binary, and binaryType is set to "blob", then initialise event's data attribute to a new Blob object that represents data as its raw data.
*If type indicates that the data is Binary, and binaryType is set to "arraybuffer", then initialise event's data attribute to a new ArrayBuffer object whose contents are data.
*Dispatch event at the WebSocket object.

==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Proposed Test Cases==

The test cases for websocket are already included in servo, under the Servo directory tests/wpt/web-platform-tests/websockets. To break down how each should be tested, here are the proposed scenarios:
* The send function should send some object, then wait for confirmation of sending.
* The constructor should make a websocket connection to the URL and either open the connection or close it based on the response coming in.
* The receive function should trigger on receiving an object, then send confirmation.

All of these are tested thoroughly in the directory given at the beginning of this section.

==Further Readings==
[https://html.spec.whatwg.org/multipage/comms.html#network HTML Spec for WebSockets] 
[https://github.com/servo/servo/wiki/WebSocket-student-project Mozilla Websocket Project Page] 
[https://github.com/servo/servo Servo github] 
[http://cyderize.github.io/rust-websocket/ Rust Websocket] 

==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-04-02T01:56:02Z

Wpgallih: /* Further Readings */

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
The requirements for the implementation is well detailed in the HTML spec shown here [https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

==Implementation==
'''When the WebSocket connection is established, the user agent must queue a task to run these steps:'''
*If the WebSocket object's client-specified protocols was not an empty list, but the subprotocol in use is the null value, then fail the WebSocket connection, set the readyState attribute's value to CLOSING, and abort these steps.
*Change the readyState attribute's value to OPEN.
*Change the extensions attribute's value to the extensions in use, if is not the null value.
*Change the protocol attribute's value to the subprotocol in use, if is not the null value.
*Act as if the user agent had received a set-cookie-string consisting of the cookies set during the server's opening handshake, for the URL url given to the WebSocket() constructor.
*Fire a simple event named open at the WebSocket object.

'''When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps:'''
*If the readyState attribute's value is not OPEN, then abort these steps.
*Let event be a newly created trusted event that uses the MessageEvent interface, with the event type message, which does not bubble, is not cancelable, and has no default action.
*Initialise event's origin attribute to the Unicode serialisation of the origin of the URL that was passed to the WebSocket object's constructor.
*If type indicates that the data is Text, then initialise event's data attribute to data.
*If type indicates that the data is Binary, and binaryType is set to "blob", then initialise event's data attribute to a new Blob object that represents data as its raw data.
*If type indicates that the data is Binary, and binaryType is set to "arraybuffer", then initialise event's data attribute to a new ArrayBuffer object whose contents are data.
*Dispatch event at the WebSocket object.

==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Proposed Test Cases==

The test cases for websocket are already included in servo, under the Servo directory tests/wpt/web-platform-tests/websockets. To break down how each should be tested, here are the proposed scenarios:
* The send function should send some object, then wait for confirmation of sending.
* The constructor should make a websocket connection to the URL and either open the connection or close it based on the response coming in.
* The receive function should trigger on receiving an object, then send confirmation.

All of these are tested thoroughly in the directory given at the beginning of this section.

==Further Readings==
[https://html.spec.whatwg.org/multipage/comms.html#network HTML Spec for WebSockets]
[https://github.com/servo/servo/wiki/WebSocket-student-project Mozilla Websocket Project Page]
[https://github.com/servo/servo Servo github]
[http://cyderize.github.io/rust-websocket/ Rust Websocket]

==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-04-02T01:55:26Z

Wpgallih: /* Further Readings */

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
The requirements for the implementation is well detailed in the HTML spec shown here [https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

==Implementation==
'''When the WebSocket connection is established, the user agent must queue a task to run these steps:'''
*If the WebSocket object's client-specified protocols was not an empty list, but the subprotocol in use is the null value, then fail the WebSocket connection, set the readyState attribute's value to CLOSING, and abort these steps.
*Change the readyState attribute's value to OPEN.
*Change the extensions attribute's value to the extensions in use, if is not the null value.
*Change the protocol attribute's value to the subprotocol in use, if is not the null value.
*Act as if the user agent had received a set-cookie-string consisting of the cookies set during the server's opening handshake, for the URL url given to the WebSocket() constructor.
*Fire a simple event named open at the WebSocket object.

'''When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps:'''
*If the readyState attribute's value is not OPEN, then abort these steps.
*Let event be a newly created trusted event that uses the MessageEvent interface, with the event type message, which does not bubble, is not cancelable, and has no default action.
*Initialise event's origin attribute to the Unicode serialisation of the origin of the URL that was passed to the WebSocket object's constructor.
*If type indicates that the data is Text, then initialise event's data attribute to data.
*If type indicates that the data is Binary, and binaryType is set to "blob", then initialise event's data attribute to a new Blob object that represents data as its raw data.
*If type indicates that the data is Binary, and binaryType is set to "arraybuffer", then initialise event's data attribute to a new ArrayBuffer object whose contents are data.
*Dispatch event at the WebSocket object.

==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Proposed Test Cases==

The test cases for websocket are already included in servo, under the Servo directory tests/wpt/web-platform-tests/websockets. To break down how each should be tested, here are the proposed scenarios:
* The send function should send some object, then wait for confirmation of sending.
* The constructor should make a websocket connection to the URL and either open the connection or close it based on the response coming in.
* The receive function should trigger on receiving an object, then send confirmation.

All of these are tested thoroughly in the directory given at the beginning of this section.

==Further Readings==
[https://html.spec.whatwg.org/multipage/comms.html#network HTML Spec for WebSockets]
[https://github.com/servo/servo/wiki/WebSocket-student-project Mozilla Websocket Project Page]
[https://github.com/servo/servo Servo github]
[http://cyderize.github.io/rust-websocket/ Rust Websocket]

==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-04-02T01:53:04Z

Wpgallih: /* Proposed Test Cases */

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
The requirements for the implementation is well detailed in the HTML spec shown here [https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

==Implementation==
'''When the WebSocket connection is established, the user agent must queue a task to run these steps:'''
*If the WebSocket object's client-specified protocols was not an empty list, but the subprotocol in use is the null value, then fail the WebSocket connection, set the readyState attribute's value to CLOSING, and abort these steps.
*Change the readyState attribute's value to OPEN.
*Change the extensions attribute's value to the extensions in use, if is not the null value.
*Change the protocol attribute's value to the subprotocol in use, if is not the null value.
*Act as if the user agent had received a set-cookie-string consisting of the cookies set during the server's opening handshake, for the URL url given to the WebSocket() constructor.
*Fire a simple event named open at the WebSocket object.

'''When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps:'''
*If the readyState attribute's value is not OPEN, then abort these steps.
*Let event be a newly created trusted event that uses the MessageEvent interface, with the event type message, which does not bubble, is not cancelable, and has no default action.
*Initialise event's origin attribute to the Unicode serialisation of the origin of the URL that was passed to the WebSocket object's constructor.
*If type indicates that the data is Text, then initialise event's data attribute to data.
*If type indicates that the data is Binary, and binaryType is set to "blob", then initialise event's data attribute to a new Blob object that represents data as its raw data.
*If type indicates that the data is Binary, and binaryType is set to "arraybuffer", then initialise event's data attribute to a new ArrayBuffer object whose contents are data.
*Dispatch event at the WebSocket object.

==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Proposed Test Cases==

The test cases for websocket are already included in servo, under the Servo directory tests/wpt/web-platform-tests/websockets. To break down how each should be tested, here are the proposed scenarios:
* The send function should send some object, then wait for confirmation of sending.
* The constructor should make a websocket connection to the URL and either open the connection or close it based on the response coming in.
* The receive function should trigger on receiving an object, then send confirmation.

All of these are tested thoroughly in the directory given at the beginning of this section.

==Further Readings==
==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-04-02T01:43:37Z

Wpgallih:

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
The requirements for the implementation is well detailed in the HTML spec shown here [https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

==Implementation==
'''When the WebSocket connection is established, the user agent must queue a task to run these steps:'''
*If the WebSocket object's client-specified protocols was not an empty list, but the subprotocol in use is the null value, then fail the WebSocket connection, set the readyState attribute's value to CLOSING, and abort these steps.
*Change the readyState attribute's value to OPEN.
*Change the extensions attribute's value to the extensions in use, if is not the null value.
*Change the protocol attribute's value to the subprotocol in use, if is not the null value.
*Act as if the user agent had received a set-cookie-string consisting of the cookies set during the server's opening handshake, for the URL url given to the WebSocket() constructor.
*Fire a simple event named open at the WebSocket object.

'''When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps:'''
*If the readyState attribute's value is not OPEN, then abort these steps.
*Let event be a newly created trusted event that uses the MessageEvent interface, with the event type message, which does not bubble, is not cancelable, and has no default action.
*Initialise event's origin attribute to the Unicode serialisation of the origin of the URL that was passed to the WebSocket object's constructor.
*If type indicates that the data is Text, then initialise event's data attribute to data.
*If type indicates that the data is Binary, and binaryType is set to "blob", then initialise event's data attribute to a new Blob object that represents data as its raw data.
*If type indicates that the data is Binary, and binaryType is set to "arraybuffer", then initialise event's data attribute to a new ArrayBuffer object whose contents are data.
*Dispatch event at the WebSocket object.

==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Proposed Test Cases==
==Further Readings==
==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-04-02T01:43:16Z

Wpgallih: /* Requirement Analysis */

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
The requirements for the implementation is well detailed in the HTML spec shown here [https://html.spec.whatwg.org/multipage/comms.html#feedback-from-the-protocol]. The majority of the requirements have to do with the feedback for the protocol. The entire reading can be seen there.

Outside of the HTML spec, a couple other requirements are necessary. First, Servo must successfully compile with the websocket components included. There are a number of warnings currently with compiling Servo not related to Websocket, but no new ones should be introduced.

Second, we should pass a set of tests already included in Servo's tests/wpt/web-platform-tests/websockets directory. These tests determine if the current websocket implementation fulfills all the requirements for Servo's use.

Finally, we should successfully issue pull requests for each feature as it is completed.

==Implementation==
'''When the WebSocket connection is established, the user agent must queue a task to run these steps:'''
*If the WebSocket object's client-specified protocols was not an empty list, but the subprotocol in use is the null value, then fail the WebSocket connection, set the readyState attribute's value to CLOSING, and abort these steps.
*Change the readyState attribute's value to OPEN.
*Change the extensions attribute's value to the extensions in use, if is not the null value.
*Change the protocol attribute's value to the subprotocol in use, if is not the null value.
*Act as if the user agent had received a set-cookie-string consisting of the cookies set during the server's opening handshake, for the URL url given to the WebSocket() constructor.
*Fire a simple event named open at the WebSocket object.

'''When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps:'''
*If the readyState attribute's value is not OPEN, then abort these steps.
*Let event be a newly created trusted event that uses the MessageEvent interface, with the event type message, which does not bubble, is not cancelable, and has no default action.
*Initialise event's origin attribute to the Unicode serialisation of the origin of the URL that was passed to the WebSocket object's constructor.
*If type indicates that the data is Text, then initialise event's data attribute to data.
*If type indicates that the data is Binary, and binaryType is set to "blob", then initialise event's data attribute to a new Blob object that represents data as its raw data.
*If type indicates that the data is Binary, and binaryType is set to "arraybuffer", then initialise event's data attribute to a new ArrayBuffer object whose contents are data.
*Dispatch event at the WebSocket object.

==Architecture==
==Component Design==
==Data Design==
==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Proposed Test Cases==
==Further Readings==
==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-04-02T01:13:55Z

Wpgallih: /* Project Description */

==Implement Rust Websocket==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo

==Introduction==
Servo<ref> https://github.com/servo/servo </ref> is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. It is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism. Implementing WebSocket API for the Servo engine would allow a persistent single TCP socket connection to be established between the client and server that will provide bi-directional, full duplex, messages to be instantly exchanged with little overhead resulting in a very low latency connection and supporting interactive, dynamic applications.

===Rust===
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

===WebSocket===
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

===Cargo and Crate===
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code> 

Cargo introduces two metadata files with various bits of project information, fetches and builds project's dependencies, invokes rustc or another build tool with the correct parameters to build the project.

==Project Description==

The goal of this project is to implement WebSocket functionality in to Servo using the Rust WebSocket project. Once this is completed, tests following the HTML spec [https://html.spec.whatwg.org/multipage/comms.html#network] for websockets should pass, as the same spec will be driving development. The project will be completed when the following conditions are true, and all tests have passed.
* The client can establish a websocket connection
* The client can send objects to the server through the websocket
* The client can receive objects from the server through the websocket
* The client can successfully close the Websocket

If Servo, as the client, is able to successfully perform all of these tasks, then our project will be completed.

==Requirement Analysis==
==Implementation==
'''When the WebSocket connection is established, the user agent must queue a task to run these steps:'''
*If the WebSocket object's client-specified protocols was not an empty list, but the subprotocol in use is the null value, then fail the WebSocket connection, set the readyState attribute's value to CLOSING, and abort these steps.
*Change the readyState attribute's value to OPEN.
*Change the extensions attribute's value to the extensions in use, if is not the null value.
*Change the protocol attribute's value to the subprotocol in use, if is not the null value.
*Act as if the user agent had received a set-cookie-string consisting of the cookies set during the server's opening handshake, for the URL url given to the WebSocket() constructor.
*Fire a simple event named open at the WebSocket object.

'''When a WebSocket message has been received with type type and data data, the user agent must queue a task to follow these steps:'''
*If the readyState attribute's value is not OPEN, then abort these steps.
*Let event be a newly created trusted event that uses the MessageEvent interface, with the event type message, which does not bubble, is not cancelable, and has no default action.
*Initialise event's origin attribute to the Unicode serialisation of the origin of the URL that was passed to the WebSocket object's constructor.
*If type indicates that the data is Text, then initialise event's data attribute to data.
*If type indicates that the data is Binary, and binaryType is set to "blob", then initialise event's data attribute to a new Blob object that represents data as its raw data.
*If type indicates that the data is Binary, and binaryType is set to "arraybuffer", then initialise event's data attribute to a new ArrayBuffer object whose contents are data.
*Dispatch event at the WebSocket object.

==Architecture==
==Component Design==
==Data Design==
==Design Patterns==
[http://en.wikipedia.org/wiki/Factory_%28object-oriented_programming%29 Factory Pattern] 
For every web application application running on the web browser that requires a websocket for communicating with the server, a new thread needs to be spawned that creates a client end of the socket associated with the web app. Spawning this thread can be considered to be similar to instantiating an object for which Factory Pattern can be employed. 
[http://en.wikipedia.org/wiki/Thread_pool_pattern Thread Pool Pattern] 
Servo's primary objective was to provide concurrency. This concurrency can be attained by scheduling tasks which can be run in parallel. Threads help execute these tasks in parallel. Thread Pool Pattern helps manage these thread. For example, one thread could be to accept new requests for websockets, as a result of which new thread would be spawned (client side of websocket) for that application.

==Proposed Test Cases==
==Further Readings==
==References==
<references/>

CSC/ECE 517 Spring 2015 M1502 WSRA

2015-04-01T06:07:55Z

Wpgallih: Created page with "==Implement Rust Websocket== ==Introduction== ==Background== ==Project Description== ==Requirement Analysis== ==Implementation== ==Architecture== ==Component Design== ==Data Desi..."

==Implement Rust Websocket==
==Introduction==
==Background==
==Project Description==
==Requirement Analysis==
==Implementation==
==Architecture==
==Component Design==
==Data Design==
==Design Patterns==
==Proposed Test Cases==
==Further Readings==
==References==

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T20:31:21Z

Wpgallih: /* Including Rust Websocket in Servo */

Implementing the WebSocket API 
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo. The project work involved making the Servo's script depend on WebSocket crate.
 
==Introduction to Mozilla Servo==
Servo is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. Servo is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism.

==Rust==
Rust <ref> https://github.com/rust-lang/rust </ref> is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

==WebSocket==
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchron3ously.

==Cargo and Crate==
Cargo <ref>http://doc.crates.io/guide.html</ref> is a application level package manager that allows Rust projects to declare their various dependencies. Cargo resembles the Bundler in Rails that is used to run Rails app, install required Gems mentioned in the Gemfile. Gemfile correspond to <code> Cargo.toml </code> file and Gem correspond to <code> Crates </code>

==Project Description==
The goal of this project was to incorporate the websocket crate in to servo, using the up to date rust websocket crate instructions. To do that, Rust's crate manager and how it interacted with servo's Mach tool was explored.

===The Crate Manager===
To incorporate new crates in to a project in rust, two main tasks are needed. First, depending on the crate that is used, a dependency needs to be added to the relevant Cargo.toml. For servo and websocket, that Cargo.toml is related to the script component, found in servo's components/script folder. To add a dependency to the Cargo.toml file, a couple different methods are available, both with separate advantages.

The first method is the simplest, and allows specification of crate versions through a method similar to Ruby gemfiles. Simply navigate to the <code>[dependencies]</code> section of the Cargo.toml, and add the crate and the version, like this example with websocket:

<pre>
[dependencies]
...
websocket = "0.11.0"
</pre>

You can vary this with other options, like ~, as in Ruby, to specify that the latest crate should be loaded or an exact version.

The second method of adding a dependency allows for far more flexibility. A crate's git repository can be added directly to the Cargo.toml, as well as many options to use particular branches, versions, and revisions.
The syntax for these dependencies is shown below.

<pre>
[dependency.crate_name]
git = "path_to_crate_git"
//other options
</pre>

Other options that are particularly useful include the ability to choose branches and revisions. Each of these options are shown below.

<pre>
branch = "name_of_branch"
rev = "hash_of_commit"
</pre>

The next step for adding a crate to a servo project requires modifying the main.rs or lib.rs, depending on which is being used for the project. Normally, the main.rs is used for the primary package, where other parts of a project may only use a lib.rs. To add a crate in either of these files, use the code shown below.

<pre>
extern crate crate_name
</pre>

Further uses of Cargo and other syntax beyond what is discussed in this article can be found [http://doc.crates.io/guide.html here].

===Including Rust Websocket in Servo===

To include the Rust Websocket crate in to Servo, an earlier version of the crate needs to be used. This is because of hyper crate dependencies. In hyper 0.3.2, method accesses were modified. Servo runs on a precompiled version of rust, one that supports hyper 0.3.0. Because of the changes in hyper 0.3.2, an earlier version of Rust Websocket that relies on hyper 0.3.0 needed to be used.

The files for implementing the websocket functions can be found in the webidl folder inside of components/script directory. To allow these files to be used, our project needed to make changes to servo to allow the websocket crate to be compiled. The first file change that is necessary lies in components/script/Cargo.toml. The websocket dependency of the correct version needs to be added here.

<pre>
[dependencies]
websocket = "0.11.0"
</pre>

The second file, as described above for adding the websocket crate, is also in components/script. For this section, since the servo component is the main component, the file that needs editing is lib.rs instead of main.rs. The file is modified by adding this line with the other <code> extern </code> lines.

<pre>
extern ...
extern crate websocket;
...
</pre>

Once these files have been modified, return to the base servo directory, and run <code>./mach build</code> to compile the websocket library in to Servo.

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T20:12:55Z

Wpgallih: /* Project Description */

==M1502: Implementing the WebSocket API==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo. The project work involved making the Servo's script depend on WebSocket crate.

==Introduction to Mozilla Servo==
Servo is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. Servo is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism.

==Rust==
[https://github.com/rust-lang/rust Rust] is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

==WebSocket==
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

==Project Description==
The goal of this project was to incorporate the websocket crate in to servo, using the up to date rust websocket crate instructions. To do that, Rust's crate manager and how it interacted with servo's Mach tool was explored.

===The Crate Manager===
To incorporate new crates in to a project in rust, two main tasks are needed. First, depending on the crate that is used, a dependency needs to be added to the relevant Cargo.toml. For servo and websocket, that Cargo.toml is related to the script component, found in servo's components/script folder. To add a dependency to the Cargo.toml file, a couple different methods are available, both with separate advantages.

The first method is the simplest, and allows specification of crate versions through a method similar to Ruby gemfiles. Simply navigate to the <code>[dependencies]</code> section of the Cargo.toml, and add the crate and the version, like this example with websocket:

<pre>
[dependencies]
...
websocket = "0.11.0"
</pre>

You can vary this with other options, like ~, as in Ruby, to specify that the latest crate should be loaded or an exact version.

The second method of adding a dependency allows for far more flexibility. A crate's git repository can be added directly to the Cargo.toml, as well as many options to use particular branches, versions, and revisions.
The syntax for these dependencies is shown below.

<pre>
[dependency.crate_name]
git = "path_to_crate_git"
//other options
</pre>

Other options that are particularly useful include the ability to choose branches and revisions. Each of these options are shown below.

<pre>
branch = "name_of_branch"
rev = "hash_of_commit"
</pre>

The next step for adding a crate to a servo project requires modifying the main.rs or lib.rs, depending on which is being used for the project. Normally, the main.rs is used for the primary package, where other parts of a project may only use a lib.rs. To add a crate in either of these files, use the code shown below.

<pre>
extern crate crate_name
</pre>

Further uses of Cargo and other syntax beyond what is discussed in this article can be found here: [http://doc.crates.io/guide.html].

===Including Rust Websocket in Servo===

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T20:11:52Z

Wpgallih: /* The Crate Manager */

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T20:11:04Z

Wpgallih: /* The Crate Manager */

==M1502: Implementing the WebSocket API==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo. The project work involved making the Servo's script depend on WebSocket crate.

==Introduction to Mozilla Servo==
Servo is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. Servo is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism.

==Rust==
[https://github.com/rust-lang/rust Rust] is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

==WebSocket==
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

==Project Description==
The goal of this project was to incorporate the websocket crate in to servo, using the up to date rust websocket crate instructions. To do that, Rust's crate manager and how it interacted with servo's Mach tool was explored.

===The Crate Manager===
To incorporate new crates in to a project in rust, two main tasks are needed. First, depending on the crate that is used, a dependency needs to be added to the relevant Cargo.toml. For servo and websocket, that Cargo.toml is related to the script component, found in servo's components/script folder. To add a dependency to the Cargo.toml file, a couple different methods are available, both with separate advantages.

The first method is the simplest, and allows specification of crate versions through a method similar to Ruby gemfiles. Simply navigate to the <code>[dependencies]</code> section of the Cargo.toml, and add the crate and the version, like this example with websocket:

<pre>
[dependencies]
...
websocket = "0.11.0"
</pre>

You can vary this with other options, like ~, as in Ruby, to specify that the latest crate should be loaded or an exact version.

The second method of adding a dependency allows for far more flexibility. A crate's git repository can be added directly to the Cargo.toml, as well as many options to use particular branches, versions, and revisions.
The syntax for these dependencies is shown below.

<code>
[dependency.crate_name] 
git = "path_to_crate_git" 
//other options 
</code>

Other options that are particularly useful include the ability to choose branches and revisions. Each of these options are shown below.

<code>
branch = "name_of_branch" 
rev = "hash_of_commit" 
</code>

The next step for adding a crate to a servo project requires modifying the main.rs or lib.rs, depending on which is being used for the project. Normally, the main.rs is used for the primary package, where other parts of a project may only use a lib.rs. To add a crate in either of these files, use the code shown below.

<code>
extern crate crate_name 
</code>

Further uses of Cargo and other syntax beyond what is discussed in this article can be found here: [http://doc.crates.io/guide.html].

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T20:10:40Z

Wpgallih: /* The Crate Manager */

==M1502: Implementing the WebSocket API==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo. The project work involved making the Servo's script depend on WebSocket crate.

==Introduction to Mozilla Servo==
Servo is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. Servo is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism.

==Rust==
[https://github.com/rust-lang/rust Rust] is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

==WebSocket==
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

==Project Description==
The goal of this project was to incorporate the websocket crate in to servo, using the up to date rust websocket crate instructions. To do that, Rust's crate manager and how it interacted with servo's Mach tool was explored.

===The Crate Manager===
To incorporate new crates in to a project in rust, two main tasks are needed. First, depending on the crate that is used, a dependency needs to be added to the relevant Cargo.toml. For servo and websocket, that Cargo.toml is related to the script component, found in servo's components/script folder. To add a dependency to the Cargo.toml file, a couple different methods are available, both with separate advantages.

The first method is the simplest, and allows specification of crate versions through a method similar to Ruby gemfiles. Simply navigate to the <code>[dependencies]</code> section of the Cargo.toml, and add the crate and the version, like this example with websocket:

<code>
[dependencies] 
... 
websocket = "0.11.0" 
</code>

You can vary this with other options, like ~, as in Ruby, to specify that the latest crate should be loaded or an exact version.

The second method of adding a dependency allows for far more flexibility. A crate's git repository can be added directly to the Cargo.toml, as well as many options to use particular branches, versions, and revisions.
The syntax for these dependencies is shown below.

<code>
[dependency.crate_name] 
git = "path_to_crate_git" 
//other options 
</code>

Other options that are particularly useful include the ability to choose branches and revisions. Each of these options are shown below.

<code>
branch = "name_of_branch" 
rev = "hash_of_commit" 
</code>

The next step for adding a crate to a servo project requires modifying the main.rs or lib.rs, depending on which is being used for the project. Normally, the main.rs is used for the primary package, where other parts of a project may only use a lib.rs. To add a crate in either of these files, use the code shown below.

<code>
extern crate crate_name 
</code>

Further uses of Cargo and other syntax beyond what is discussed in this article can be found here: [http://doc.crates.io/guide.html].

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T20:10:21Z

Wpgallih: /* The Crate Manager */

==M1502: Implementing the WebSocket API==
This project concentrates on implementing Rust WebSocket API for Mozilla's web browser engine, Servo. The project work involved making the Servo's script depend on WebSocket crate.

==Introduction to Mozilla Servo==
Servo is a Web Browser engine written in [https://github.com/rust-lang/rust Rust]. Servo is an experimental project build that targets new generation of hardware: mobile devices, multi-core processors and high-performance GPUs to obtain power efficiency and maximum parallelism.

==Rust==
[https://github.com/rust-lang/rust Rust] is a Systems programming language built in Rust itself that is fast, memory safe and multithreaded, but does not employ a garbage collector or otherwise impose significant runtime overhead. Rust is able to provide both control over hardware and safety which is not the case with other programming languages like C, C++, Python that provide only either control or safety but not both.

==WebSocket==
WebSockets is a protocol that provides [http://en.wikipedia.org/wiki/Duplex_(telecommunications)#FULL-DUPLEX full-duplex] channel for a TCP connection and makes it possible to open an interactive communication session between the user's browser and a server. With WebSockets, you can send messages to a server and receive event-driven responses without having to request the server for a reply. The [http://dev.w3.org/html5/websockets/ WebSocket] specification defines an API to establish a "socket" connection between a web browser and a server. This establishment involves a handshake following which there is a persistent connection between the client and the server and both parties can start sending data asynchronously.

==Project Description==
The goal of this project was to incorporate the websocket crate in to servo, using the up to date rust websocket crate instructions. To do that, Rust's crate manager and how it interacted with servo's Mach tool was explored.

===The Crate Manager===
To incorporate new crates in to a project in rust, two main tasks are needed. First, depending on the crate that is used, a dependency needs to be added to the relevant Cargo.toml. For servo and websocket, that Cargo.toml is related to the script component, found in servo's components/script folder. To add a dependency to the Cargo.toml file, a couple different methods are available, both with separate advantages.

The first method is the simplest, and allows specification of crate versions through a method similar to Ruby gemfiles. Simply navigate to the <code>[dependencies]</code> section of the Cargo.toml, and add the crate and the version, like this example with websocket:

<code>
[dependencies] 
... 
websocket = "0.11.0" 
</code>

You can vary this with other options, like ~, as in Ruby, to specify that the latest crate should be loaded or an exact version.

The second method of adding a dependency allows for far more flexibility. A crate's git repository can be added directly to the Cargo.toml, as well as many options to use particular branches, versions, and revisions.
The syntax for these dependencies is shown below.

<code>
[dependency.crate_name] 
git = "path_to_crate_git" 
//other options 
</code>

Other options that are particularly useful include the ability to choose branches and revisions. Each of these options are shown below.

<code>
branch = "name_of_branch" 
rev = "hash_of_commit" 
<code>

The next step for adding a crate to a servo project requires modifying the main.rs or lib.rs, depending on which is being used for the project. Normally, the main.rs is used for the primary package, where other parts of a project may only use a lib.rs. To add a crate in either of these files, use the code shown below.

<code>
extern crate crate_name 
<code>

Further uses of Cargo and other syntax beyond what is discussed in this article can be found here: [http://doc.crates.io/guide.html].

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T19:55:55Z

Wpgallih: /* The Crate Manager */

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T19:55:01Z

Wpgallih: /* The Crate Manager */

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T19:54:43Z

Wpgallih:

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T09:58:59Z

Wpgallih:

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T09:46:58Z

Wpgallih:

CSC/ECE 517 Spring 2015/oss M1502 GVJ

2015-03-23T09:46:35Z

Wpgallih:

CSC/ECE 517 Spring 2015/ch1a 2 WA

2015-02-16T22:25:16Z

Wpgallih:

Knife
[[File:workstation.png|frame|Source: https://docs.chef.io/chef_quick_overview.html|right]]
Knife is the command line tool for managing Chef nodes. Simply, Chef allows the distribution of server environments between many different servers (called '''nodes'''). Any changes to the primary chef server (called the '''chef repo''' are distributed throughout all the other nodes, while different nodes can have other recipes and send them back to the chef repo. Knife, then, handles the communication between nodes and the chef repo. For example, let's say that there is an object on the chef repo that a node desires. Knife provides the tools to download that object to the node. Knife also allows setting up a node, installing necessary packages, management of users, and much more.

The topic writeup for this page can be found [https://docs.google.com/document/d/1TgBtp7flIPKJwkkShgtcIkt--mtHuwVHsQX6Tpzj1rc/edit here].

== Background ==

Chef streamlines the task of configuring and maintaining a company's servers, and can integrate with cloud-based platforms. Chef is an IT and environment distribution system, built to be robust and scalable. Imagine a large scale internet based company. Depending on the demands of the company, they may have a need for development workstations, servers for purchasing products, servers for hosting games, even clients for games or accessing databases. All of these different environments are called ''chef client nodes'', with each different setup as different ''environments''. For example, you might have ten chef client nodes set up with the development environment, and one hundred chef client nodes set up with the server environment. The chef server contains all of the ''recipes'', reusable code that may be needed both for use and setup of different chef client nodes, to set up all of the different environments that have been defined. In addition, the chef server works like other versioning software. This means you can roll out updates conveniently to all of the different chef client nodes with ease. This allows the entire collection of chef, the recipes, environments, and nodes, called the ''infrastructure'', to be managed simply and in defined, scalable versions.
Chef is more complex and allows other little tricks and nuances. If you want to learn more about Chef itself, beyond the description found here, check out the comparison between Chef and Puppet here: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/ch1_1w10_ga] or take a look at the official Chef website here: <ref>[https://www.chef.io/ Chef]</ref>, which are the sources for the information in this background. This description just serves to introduce the concept of chef, so that knife's purpose can be understood. These other pages cover the ideas of Chef and how to use it effectively in more detail. In fact, the main site for Chef has an interactive tutorial in setting up a Chef server, without even having to use a personal server or computer. However, the rest of this article will be describing and covering knife.

== What is Knife? ==

Chef includes two important command-line tools.
*Knife command-line tool
*Chef command-line tool

knife is the command-line tool that provides an interface between a local chef client node and the Chef server. Where the Chef command-line tool is used while working with the chef server and repo, Knife helps us to manage the following:

* Nodes
* JSON data Stores
* Environments
* chef-clients installations on management workstations

Basically, the chef command tool deals with the actual chef installation wherever it is, either a local installation and on the server. It deals only with itself. Knife, however, deals with the setup of all the communication and objects between the chef server and a chef client node.

<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:chef_knife server.png]] <ref>[http://dev.classmethod.jp/server-side/chef-server-install/ Chef Server]</ref></div>

In the figure, we can see that how knife provides an interface between local repository's and Chef server at the workstation.

== Using Knife ==

Using Knife is fairly straightforward, with usage following this syntax:

<pre> knife [verb] [object] [options] </pre>

The different verbs, or subcommands, for Knife are as follows, from the Using Knife page<ref> [https://docs.chef.io/knife_using.html Knife Documents]</ref>: bootstrap, client, configure, cookbook, cookbook site, data bag, delete, deps, diff, download, edit, environment, exec, index rebuild, list, node, recipe list, role, search, show, ssh, status, tag, upload, user, and xargs.

'''Warning:''' Before you run many of these commands, you should have the knife editor set correctly. In the chef-repo, there are multiple ruby files that set the configuration of the environment. Inside of knife.rb, you need to add or set the following line.

<pre>
<syntaxhighlight lang="ruby">
knife[:editor] = "/usr/bin/vim"
</syntaxhighlight>
</pre>

The path can be set to the text editor of choice, the above command sets the editor to vim.

The example we will use is also one that is useful for setting up nodes, and that is the usage of the bootstrap command. To set up a node, go to the command line on the chef repo and execute the following command:

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo </pre>

First, the verb used is '''bootstrap'''. Bootstrap is the subcommand that allows the installation of a chef client on to a targeted node.
Second, the object is the ip_address_of_node. Every subcommand takes an object, and since chef operates on many ruby principles and scripts, the object can be most anything. For boostrap, this object is the ip of the server address. For other commands, this might be something different.
Third, we have the options for the bootstrap command and the object. For bootstrap, this includes the username and password for the node, and the option --sudo, to make sure all commands are executed correctly.

Before we do the next example, let's cover an important part of object strings and how they are treated by knife and the chef repo.

'''Wildcards'''
A wildcard search can be used similar to standard regex commands, with one notable difference. The wildcard character itself '''must be escaped using the \ character.''' Here is an example from the "Using Knife" page on the chef website. Let's say the following was used to search for an object:

<pre>data_bags/a\*</pre>

Will return all of the objects that start with data_bags\a on the chef-node. However, if we were to run the following:

<pre>data_bags/a*</pre>

Will only search for objects on the chef repo corresponding to objects starting with data_bags/a on the node. Therefore, the * was applied '''before''' being sent to the chef repo, instead of after. So, as an example, let us list all of the data bags that are on the server that start with 'a'. Our object, then, is the string above, <code>data_bags/a\*</code>. The verb that lists different objects on the chef repo is called <code>list</code>. Our command we would run would be this:

<pre>knife list data_bags/a\*</pre>

Which would print to the console all of the objects in the data_bags directory that started with a.

== Bootstrapping A Node ==

One of the key uses of knife is doing something called "bootstrapping" a node <ref>[http://docs.chef.io/open_source/install_bootstrap.html Install Bootstrap]</ref>. This key tool allows someone using the Chef server to set up a remote node, or client. Not only does knife set up all of the relevant recipes, environments, and other such things related with the chef repo itself, it also installs all of the tools necessary for interacting with the chef server and configuring the chef client. Because of this, a basic understanding in how to bootstrap a node, and some knowledge on the available options for bootstrapping a node, is important.

Luckily, bootstrapping a node is very simple. To bootstrap a node, the general command would look like this. Be aware, this is being run from the chef server.

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo --node-name name_of_node</pre>

This process will create a chef client at the designated IP adress. The username and the password is the username and password of a root access user on the remote node. The name of the node can be set here as well, instead of automatically using other settings. The option is shown here, to make the rest of the example easier to understand. Luckily, the knife bootstrap command uses an omnibus installer that automatically detects the OS of the target machine and will install all of the necessary command line tools and internal installations, like ruby, for the chef client to function. Once the bootstrap command is complete, the following message will be displayed.
<pre>INFO: Report handlers complete</pre>

However, before continuing, confirmation of the remote node is necessary. To confirm that the remote node was installed correctly and is running, run the following command.

<pre>knife client show name_of_node</pre>

Here, the name_of_node is the name of the node either set in other options and commands, such as the --node-name used above. When this is run, the node's information should be displayed, such as if the node is an admin, the name of the node, and the JSON type it was created from.

<pre>admin: false
chef_type: client
json_class: Chef::ApiClient
name: name_of_node
public_key:</pre>

== Bootstrap Options and Knife Settings ==
As one of the most powerful tools knife has to offer, the bootstrap function has many different options available to it. The "Installing Bootstrap" section covered three such options (-x, -P, and --node-name), but there are many more available that are useful. Here are a few that stand out as being useful to someone using knife bootstrap for the first time, or for people who are dealing with something outside of the normal conditions for installing and using knife bootstrap. In addition, adding different settings to the knife.rb file will be covered, for people looking to expand the usage of knife and knife bootstrap. Most of this information is covered in higher detail in the main knife bootstrap page, as well as all the other options. You can check that page out using the reference here.<ref>[http://docs.chef.io/knife_bootstrap.html Knife Boostrap]</ref>

'''--bootstrap-curl-options OPTIONS, --bootstrap-install-command COMMAND, --bootstrap-install-sh URL'''

These commands allow customization of the installation bootstrap performs. They are all mutually exclusive, but allow different ways to perform this customization. The first, bootstap-curl-options, which allows additional cURL options to be performed alongside the bootstrap installation. To learn more about cURL, check out their main web page here: ([http://curl.haxx.se/ cURL Home Page]). The second, bootstrap-install-command, allows the execution of another install command on the target node alongside the bootstrap function. The final one, bootstrap-install-sh, allows a custom install script located at the designated URL to be run, following the bootstrap command.

'''--environment ENVIRONMENT, --boostrap-template TEMPLATE'''

The --environment and --bootstrap-template commands are similar, in that they allow customization of the target node. One allows the node to be set up against a target environment, which is useful if your chef server has multiple environments available. The next allows different node setups to be saved as templates. These can be used to quickly and efficiently set up additional similar nodes, especially if the additional installation options in bootstrap are long.

'''-V'''

A small option for bootstrap, the -V option forces the initial chief-client setup to be run on the target node at the debug log level, following the bootstrap installation. This allows almost complete remote setup of new nodes, assuring that the node is ready to be used and the chef-client is fully operational and doesn't need further setup. In addition, the debug log will allow any errors in the chef client to be saved, in the case of something wrong occurring with the node. The exact command run is shown below:
<pre>chef-client -l debug</pre>

'''Custom settings and adding them to the knife.rb file'''

For some settings, including settings related to bootstrap, the options will need to be added to the knife.rb file. This file contains all of the commands for knife, and all of the different options available to these commands. For example, to use the --bootstrap-template and the --sudo options, the following commands need to be executed:
<pre>knife[:template_file]
knife[:use_sudo]</pre>
These commands add the template_file and use_sudo options to the knife.rb file, which will enable those options to be used in the bootstrap command. There are more options that can be added using the knife.rb file, the full knife documentation for commands are here: ([https://docs.chef.io/chef/knife.html# Knife Reference]).

== References ==
<references/>

CSC/ECE 517 Spring 2015/ch1a 2 WA

2015-02-09T21:12:49Z

Wpgallih:

Knife
[[File:workstation.png|frame|Source: https://docs.chef.io/chef_quick_overview.html|right]]
Knife is the command line tool for managing Chef nodes. Simply, Chef allows the distribution of server environments between many different servers (called '''nodes'''). Any changes to the primary chef server (called the '''chef repo''' are distributed throughout all the other nodes, while different nodes can have other recipes and send them back to the chef repo. Knife, then, handles the communication between nodes and the chef repo. For example, let's say that there is an object on the chef repo that a node desires. Knife provides the tools to download that object to the node. Knife also allows setting up a node, installing necessary packages, management of users, and much more.

The topic writeup for this page can be found [https://docs.google.com/document/d/1TgBtp7flIPKJwkkShgtcIkt--mtHuwVHsQX6Tpzj1rc/edit here].

== Background ==

Chef streamlines the task of configuring and maintaining a company's servers, and can integrate with cloud-based platforms.
If you are unfamiliar with Chef and how it works, check out the comparison between Chef and Puppet here: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/ch1_1w10_ga] or take a look at the official Chef website here: <ref>[https://www.chef.io/ Chef]</ref>. There, a deeper understanding of Chef can be attained.

Chef includes two important command-line tools.
*Knife command-line tool
*Chef command-line tool

knife is the command-line tool that provides an interface between a local chef-repo and the Chef server. Whereas, Chef command-line tool is used while working with the chef repo. Knife helps us to manage the following.

* Nodes
* JSON data Stores
* Environments
* chef-clients installations on management workstations

<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:chef_knife server.png]] <ref>[http://dev.classmethod.jp/server-side/chef-server-install/ Chef Server]</ref></div>

In the figure, we can see that how knife provides an interface between local repository's and Chef server at the workstation.

== Using Knife ==

Using Knife is fairly straightforward, with usage following this syntax:

<pre> knife [verb] [object] [options] </pre>

The different verbs, or subcommands, for Knife are as follows, from the Using Knife page<ref> [https://docs.chef.io/knife_using.html Knife Documents]</ref>: bootstrap, client, configure, cookbook, cookbook site, data bag, delete, deps, diff, download, edit, environment, exec, index rebuild, list, node, recipe list, role, search, show, ssh, status, tag, upload, user, and xargs.

'''Warning:''' Before you run many of these commands, you should have the knife editor set correctly. In the chef-repo, there are multiple ruby files that set the configuration of the environment. Inside of knife.rb, you need to add or set the following line.

<pre>
<syntaxhighlight lang="ruby">
knife[:editor] = "/usr/bin/vim"
</syntaxhighlight>
</pre>

The path can be set to the text editor of choice, the above command sets the editor to vim.

The example we will use is also one that is useful for setting up nodes, and that is the usage of the bootstrap command. To set up a node, go to the command line on the chef repo and execute the following command:

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo </pre>

First, the verb used is '''bootstrap'''. Bootstrap is the subcommand that allows the installation of a chef client on to a targeted node.
Second, the object is the ip_address_of_node. Every subcommand takes an object, and since chef operates on many ruby principles and scripts, the object can be most anything. For boostrap, this object is the ip of the server address. For other commands, this might be something different.
Third, we have the options for the bootstrap command and the object. For bootstrap, this includes the username and password for the node, and the option --sudo, to make sure all commands are executed correctly.

Before we do the next example, let's cover an important part of object strings and how they are treated by knife and the chef repo.

'''Wildcards'''
A wildcard search can be used similar to standard regex commands, with one notable difference. The wildcard character itself '''must be escaped using the \ character.''' Here is an example from the "Using Knife" page on the chef website. Let's say the following was used to search for an object:

<pre>data_bags/a\*</pre>

Will return all of the objects that start with data_bags\a on the chef-node. However, if we were to run the following:

<pre>data_bags/a*</pre>

Will only search for objects on the chef repo corresponding to objects starting with data_bags/a on the node. Therefore, the * was applied '''before''' being sent to the chef repo, instead of after. So, as an example, let us list all of the data bags that are on the server that start with 'a'. Our object, then, is the string above, <code>data_bags/a\*</code>. The verb that lists different objects on the chef repo is called <code>list</code>. Our command we would run would be this:

<pre>knife list data_bags/a\*</pre>

Which would print to the console all of the objects in the data_bags directory that started with a.

== Bootstrapping A Node ==

One of the key uses of knife is doing something called "bootstrapping" a node <ref>[http://docs.chef.io/open_source/install_bootstrap.html Install Bootstrap]</ref>. This key tool allows someone using the Chef server to set up a remote node, or client. Not only does knife set up all of the relevant recipes, environments, and other such things related with the chef repo itself, it also installs all of the tools necessary for interacting with the chef server and configuring the chef client. Because of this, a basic understanding in how to bootstrap a node, and some knowledge on the available options for bootstrapping a node, is important.

Luckily, bootstrapping a node is very simple. To bootstrap a node, the general command would look like this. Be aware, this is being run from the chef server.

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo --node-name name_of_node</pre>

This process will create a chef client at the designated IP adress. The username and the password is the username and password of a root access user on the remote node. The name of the node can be set here as well, instead of automatically using other settings. The option is shown here, to make the rest of the example easier to understand. Luckily, the knife bootstrap command uses an omnibus installer that automatically detects the OS of the target machine and will install all of the necessary command line tools and internal installations, like ruby, for the chef client to function. Once the bootstrap command is complete, the following message will be displayed.
<pre>INFO: Report handlers complete</pre>

However, before continuing, confirmation of the remote node is necessary. To confirm that the remote node was installed correctly and is running, run the following command.

<pre>knife client show name_of_node</pre>

Here, the name_of_node is the name of the node either set in other options and commands, such as the --node-name used above. When this is run, the node's information should be displayed, such as if the node is an admin, the name of the node, and the JSON type it was created from.

<pre>admin: false
chef_type: client
json_class: Chef::ApiClient
name: name_of_node
public_key:</pre>

== Bootstrap Options and Knife Settings ==
As one of the most powerful tools knife has to offer, the bootstrap function has many different options available to it. The "Installing Bootstrap" section covered three such options (-x, -P, and --node-name), but there are many more available that are useful. Here are a few that stand out as being useful to someone using knife bootstrap for the first time, or for people who are dealing with something outside of the normal conditions for installing and using knife bootstrap. In addition, adding different settings to the knife.rb file will be covered, for people looking to expand the usage of knife and knife bootstrap. Most of this information is covered in higher detail in the main knife bootstrap page, as well as all the other options. You can check that page out using the reference here.<ref>[http://docs.chef.io/knife_bootstrap.html Knife Boostrap]</ref>

'''--bootstrap-curl-options OPTIONS, --bootstrap-install-command COMMAND, --bootstrap-install-sh URL'''

These commands allow customization of the installation bootstrap performs. They are all mutually exclusive, but allow different ways to perform this customization. The first, bootstap-curl-options, which allows additional cURL options to be performed alongside the bootstrap installation. To learn more about cURL, check out their main web page here: ([http://curl.haxx.se/ cURL Home Page]). The second, bootstrap-install-command, allows the execution of another install command on the target node alongside the bootstrap function. The final one, bootstrap-install-sh, allows a custom install script located at the designated URL to be run, following the bootstrap command.

'''--environment ENVIRONMENT, --boostrap-template TEMPLATE'''

The --environment and --bootstrap-template commands are similar, in that they allow customization of the target node. One allows the node to be set up against a target environment, which is useful if your chef server has multiple environments available. The next allows different node setups to be saved as templates. These can be used to quickly and efficiently set up additional similar nodes, especially if the additional installation options in bootstrap are long.

'''-V'''

A small option for bootstrap, the -V option forces the initial chief-client setup to be run on the target node at the debug log level, following the bootstrap installation. This allows almost complete remote setup of new nodes, assuring that the node is ready to be used and the chef-client is fully operational and doesn't need further setup. In addition, the debug log will allow any errors in the chef client to be saved, in the case of something wrong occurring with the node. The exact command run is shown below:
<pre>chef-client -l debug</pre>

'''Custom settings and adding them to the knife.rb file'''

For some settings, including settings related to bootstrap, the options will need to be added to the knife.rb file. This file contains all of the commands for knife, and all of the different options available to these commands. For example, to use the --bootstrap-template and the --sudo options, the following commands need to be executed:
<pre>knife[:template_file]
knife[:use_sudo]</pre>
These commands add the template_file and use_sudo options to the knife.rb file, which will enable those options to be used in the bootstrap command. There are more options that can be added using the knife.rb file, the full knife documentation for commands are here: ([https://docs.chef.io/chef/knife.html# Knife Reference]).

== References ==
<references/>

CSC/ECE 517 Spring 2015/ch1a 2 WA

2015-02-09T21:03:58Z

Wpgallih: /* Bootstrap Options and Knife Settings */

Knife
[[File:workstation.png|frame|Source: https://docs.chef.io/chef_quick_overview.html|right]]
Knife is the command line tool for managing Chef nodes. Simply, Chef allows the distribution of server environments between many different servers (called '''nodes'''). Any changes to the primary chef server (called the '''chef repo''' are distributed throughout all the other nodes, while different nodes can have other recipes and send them back to the chef repo. Knife, then, handles the communication between nodes and the chef repo. For example, let's say that there is an object on the chef repo that a node desires. Knife provides the tools to download that object to the node. Knife also allows setting up a node, installing necessary packages, management of users, and much more.

== Background ==

Chef streamlines the task of configuring and maintaining a company's servers, and can integrate with cloud-based platforms.
If you are unfamiliar with Chef and how it works, check out the comparison between Chef and Puppet here: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/ch1_1w10_ga] or take a look at the official Chef website here: <ref>[https://www.chef.io/ Chef]</ref>. There, a deeper understanding of Chef can be attained.

Chef includes two important command-line tools.
*Knife command-line tool
*Chef command-line tool

knife is the command-line tool that provides an interface between a local chef-repo and the Chef server. Whereas, Chef command-line tool is used while working with the chef repo. Knife helps us to manage the following.

* Nodes
* JSON data Stores
* Environments
* chef-clients installations on management workstations

<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:chef_knife server.png]] <ref>[http://dev.classmethod.jp/server-side/chef-server-install/ Chef Server]</ref></div>

In the figure, we can see that how knife provides an interface between local repository's and Chef server at the workstation.

== Using Knife ==

Using Knife is fairly straightforward, with usage following this syntax:

<pre> knife [verb] [object] [options] </pre>

The different verbs, or subcommands, for Knife are as follows, from the Using Knife page<ref> [https://docs.chef.io/knife_using.html Knife Documents]</ref>: bootstrap, client, configure, cookbook, cookbook site, data bag, delete, deps, diff, download, edit, environment, exec, index rebuild, list, node, recipe list, role, search, show, ssh, status, tag, upload, user, and xargs.

'''Warning:''' Before you run many of these commands, you should have the knife editor set correctly. In the chef-repo, there are multiple ruby files that set the configuration of the environment. Inside of knife.rb, you need to add or set the following line.

<pre>
<syntaxhighlight lang="ruby">
knife[:editor] = "/usr/bin/vim"
</syntaxhighlight>
</pre>

The path can be set to the text editor of choice, the above command sets the editor to vim.

The example we will use is also one that is useful for setting up nodes, and that is the usage of the bootstrap command. To set up a node, go to the command line on the chef repo and execute the following command:

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo </pre>

First, the verb used is '''bootstrap'''. Bootstrap is the subcommand that allows the installation of a chef client on to a targeted node.
Second, the object is the ip_address_of_node. Every subcommand takes an object, and since chef operates on many ruby principles and scripts, the object can be most anything. For boostrap, this object is the ip of the server address. For other commands, this might be something different.
Third, we have the options for the bootstrap command and the object. For bootstrap, this includes the username and password for the node, and the option --sudo, to make sure all commands are executed correctly.

Before we do the next example, let's cover an important part of object strings and how they are treated by knife and the chef repo.

'''Wildcards'''
A wildcard search can be used similar to standard regex commands, with one notable difference. The wildcard character itself '''must be escaped using the \ character.''' Here is an example from the "Using Knife" page on the chef website. Let's say the following was used to search for an object:

<pre>data_bags/a\*</pre>

Will return all of the objects that start with data_bags\a on the chef-node. However, if we were to run the following:

<pre>data_bags/a*</pre>

Will only search for objects on the chef repo corresponding to objects starting with data_bags/a on the node. Therefore, the * was applied '''before''' being sent to the chef repo, instead of after. So, as an example, let us list all of the data bags that are on the server that start with 'a'. Our object, then, is the string above, <code>data_bags/a\*</code>. The verb that lists different objects on the chef repo is called <code>list</code>. Our command we would run would be this:

<pre>knife list data_bags/a\*</pre>

Which would print to the console all of the objects in the data_bags directory that started with a.

== Bootstrapping A Node ==

One of the key uses of knife is doing something called "bootstrapping" a node <ref>[http://docs.chef.io/open_source/install_bootstrap.html Install Bootstrap]</ref>. This key tool allows someone using the Chef server to set up a remote node, or client. Not only does knife set up all of the relevant recipes, environments, and other such things related with the chef repo itself, it also installs all of the tools necessary for interacting with the chef server and configuring the chef client. Because of this, a basic understanding in how to bootstrap a node, and some knowledge on the available options for bootstrapping a node, is important.

Luckily, bootstrapping a node is very simple. To bootstrap a node, the general command would look like this. Be aware, this is being run from the chef server.

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo --node-name name_of_node</pre>

This process will create a chef client at the designated IP adress. The username and the password is the username and password of a root access user on the remote node. The name of the node can be set here as well, instead of automatically using other settings. The option is shown here, to make the rest of the example easier to understand. Luckily, the knife bootstrap command uses an omnibus installer that automatically detects the OS of the target machine and will install all of the necessary command line tools and internal installations, like ruby, for the chef client to function. Once the bootstrap command is complete, the following message will be displayed.
<pre>INFO: Report handlers complete</pre>

However, before continuing, confirmation of the remote node is necessary. To confirm that the remote node was installed correctly and is running, run the following command.

<pre>knife client show name_of_node</pre>

Here, the name_of_node is the name of the node either set in other options and commands, such as the --node-name used above. When this is run, the node's information should be displayed, such as if the node is an admin, the name of the node, and the JSON type it was created from.

<pre>admin: false
chef_type: client
json_class: Chef::ApiClient
name: name_of_node
public_key:</pre>

== Bootstrap Options and Knife Settings ==
As one of the most powerful tools knife has to offer, the bootstrap function has many different options available to it. The "Installing Bootstrap" section covered three such options (-x, -P, and --node-name), but there are many more available that are useful. Here are a few that stand out as being useful to someone using knife bootstrap for the first time, or for people who are dealing with something outside of the normal conditions for installing and using knife bootstrap. In addition, adding different settings to the knife.rb file will be covered, for people looking to expand the usage of knife and knife bootstrap. Most of this information is covered in higher detail in the main knife bootstrap page, as well as all the other options. You can check that page out using the reference here.<ref>[http://docs.chef.io/knife_bootstrap.html Knife Boostrap]</ref>

'''--bootstrap-curl-options OPTIONS, --bootstrap-install-command COMMAND, --bootstrap-install-sh URL'''

These commands allow customization of the installation bootstrap performs. They are all mutually exclusive, but allow different ways to perform this customization. The first, bootstap-curl-options, which allows additional cURL options to be performed alongside the bootstrap installation. To learn more about cURL, check out their main web page here: ([http://curl.haxx.se/ cURL Home Page]). The second, bootstrap-install-command, allows the execution of another install command on the target node alongside the bootstrap function. The final one, bootstrap-install-sh, allows a custom install script located at the designated URL to be run, following the bootstrap command.

'''--environment ENVIRONMENT, --boostrap-template TEMPLATE'''

The --environment and --bootstrap-template commands are similar, in that they allow customization of the target node. One allows the node to be set up against a target environment, which is useful if your chef server has multiple environments available. The next allows different node setups to be saved as templates. These can be used to quickly and efficiently set up additional similar nodes, especially if the additional installation options in bootstrap are long.

'''-V'''

A small option for bootstrap, the -V option forces the initial chief-client setup to be run on the target node at the debug log level, following the bootstrap installation. This allows almost complete remote setup of new nodes, assuring that the node is ready to be used and the chef-client is fully operational and doesn't need further setup. In addition, the debug log will allow any errors in the chef client to be saved, in the case of something wrong occurring with the node. The exact command run is shown below:
<pre>chef-client -l debug</pre>

'''Custom settings and adding them to the knife.rb file'''

For some settings, including settings related to bootstrap, the options will need to be added to the knife.rb file. This file contains all of the commands for knife, and all of the different options available to these commands. For example, to use the --bootstrap-template and the --sudo options, the following commands need to be executed:
<pre>knife[:template_file]
knife[:use_sudo]</pre>
These commands add the template_file and use_sudo options to the knife.rb file, which will enable those options to be used in the bootstrap command. There are more options that can be added using the knife.rb file, the full knife documentation for commands are here: ([https://docs.chef.io/chef/knife.html# Knife Reference]).

== References ==
<references/>

CSC/ECE 517 Spring 2015/ch1a 2 WA

2015-02-09T20:49:32Z

Wpgallih: /* Bootstrap Options and Knife Settings */

Knife

Knife is the command line tool for managing Chef nodes. Simply, Chef allows the distribution of server environments between many different servers (called '''nodes'''). Any changes to the primary chef server (called the '''chef repo''' are distributed throughout all the other nodes, while different nodes can have other recipes and send them back to the chef repo. Knife, then, handles the communication between nodes and the chef repo. For example, let's say that there is an object on the chef repo that a node desires. Knife provides the tools to download that object to the node. Knife also allows setting up a node, installing necessary packages, management of users, and much more.

== Background ==

Chef streamlines the task of configuring and maintaining a company's servers, and can integrate with cloud-based platforms.
If you are unfamiliar with Chef and how it works, check out the comparison between Chef and Puppet here: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/ch1_1w10_ga] or take a look at the official Chef website here: <ref>[https://www.chef.io/ Chef]</ref>. There, a deeper understanding of Chef can be attained.

Chef includes two important command-line tools.
*Knife command-line tool
*Chef command-line tool

knife is the command-line tool that provides an interface between a local chef-repo and the Chef server. Whereas, Chef command-line tool is used while working with the chef repo. Knife helps us to manage the following.

* Nodes
* JSON data Stores
* Environments
* chef-clients installations on management workstations

<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:chef_knife server.png]] <ref>[http://dev.classmethod.jp/server-side/chef-server-install/ Chef Server]</ref></div>

In the figure, we can see that how knife provides an interface between local repository's and Chef server at the workstation.

== Examples ==

Using Knife is fairly straightforward, with usage following this syntax:

<pre> knife [verb] [object] [options] </pre>

The different verbs, or subcommands, for Knife are as follows, from the Using Knife page<ref> [https://docs.chef.io/knife_using.html Knife Documents]</ref>: bootstrap, client, configure, cookbook, cookbook site, data bag, delete, deps, diff, download, edit, environment, exec, index rebuild, list, node, recipe list, role, search, show, ssh, status, tag, upload, user, and xargs.

'''Warning:''' Before you run many of these commands, you should have the knife editor set correctly. In the chef-repo, there are multiple ruby files that set the configuration of the environment. Inside of knife.rb, you need to add or set the following line.

<pre>
<syntaxhighlight lang="ruby">
knife[:editor] = "/usr/bin/vim"
</syntaxhighlight>
</pre>

The path can be set to the text editor of choice, the above command sets the editor to vim.

The example we will use is also one that is useful for setting up nodes, and that is the usage of the bootstrap command. To set up a node, go to the command line on the chef repo and execute the following command:

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo </pre>

First, the verb used is '''bootstrap'''. Bootstrap is the subcommand that allows the installation of a chef client on to a targeted node.
Second, the object is the ip_address_of_node. Every subcommand takes an object, and since chef operates on many ruby principles and scripts, the object can be most anything. For boostrap, this object is the ip of the server address. For other commands, this might be something different.
Third, we have the options for the bootstrap command and the object. For bootstrap, this includes the username and password for the node, and the option --sudo, to make sure all commands are executed correctly.

Before we do the next example, let's cover an important part of object strings and how they are treated by knife and the chef repo.

'''Wildcards'''
A wildcard search can be used similar to standard regex commands, with one notable difference. The wildcard character itself '''must be escaped using the \ character.''' Here is an example from the "Using Knife" page on the chef website. Let's say the following was used to search for an object:

<pre>data_bags/a\*</pre>

Will return all of the objects that start with data_bags\a on the chef-node. However, if we were to run the following:

<pre>data_bags/a*</pre>

Will only search for objects on the chef repo corresponding to objects starting with data_bags/a on the node. Therefore, the * was applied '''before''' being sent to the chef repo, instead of after. So, as an example, let us list all of the data bags that are on the server that start with 'a'. Our object, then, is the string above, <code>data_bags/a\*</code>. The verb that lists different objects on the chef repo is called <code>list</code>. Our command we would run would be this:

<pre>knife list data_bags/a\*</pre>

Which would print to the console all of the objects in the data_bags directory that started with a.

== Bootstrapping A Node ==

One of the key uses of knife is doing something called "bootstrapping" a node <ref>[http://docs.chef.io/open_source/install_bootstrap.html Install Bootstrap]</ref>. This key tool allows someone using the Chef server to set up a remote node, or client. Not only does knife set up all of the relevant recipes, environments, and other such things related with the chef repo itself, it also installs all of the tools necessary for interacting with the chef server and configuring the chef client. Because of this, a basic understanding in how to bootstrap a node, and some knowledge on the available options for bootstrapping a node, is important.

Luckily, bootstrapping a node is very simple. To bootstrap a node, the general command would look like this. Be aware, this is being run from the chef server.

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo --node-name name_of_node</pre>

This process will create a chef client at the designated IP adress. The username and the password is the username and password of a root access user on the remote node. The name of the node can be set here as well, instead of automatically using other settings. The option is shown here, to make the rest of the example easier to understand. Luckily, the knife bootstrap command uses an omnibus installer that automatically detects the OS of the target machine and will install all of the necessary command line tools and internal installations, like ruby, for the chef client to function. Once the bootstrap command is complete, the following message will be displayed.
<pre>INFO: Report handlers complete</pre>

However, before continuing, confirmation of the remote node is necessary. To confirm that the remote node was installed correctly and is running, run the following command.

<pre>knife client show name_of_node</pre>

Here, the name_of_node is the name of the node either set in other options and commands, such as the --node-name used above. When this is run, the node's information should be displayed, such as if the node is an admin, the name of the node, and the JSON type it was created from.

<pre>admin: false
chef_type: client
json_class: Chef::ApiClient
name: name_of_node
public_key:</pre>

== Bootstrap Options and Knife Settings ==
As one of the most powerful tools knife has to offer, the bootstrap function has many different options available to it. The "Installing Bootstrap" section covered three such options (-x, -P, and --node-name), but there are many more available that are useful. Here are a few that stand out as being useful to someone using knife bootstrap for the first time, or for people who are dealing with something outside of the normal conditions for installing and using knife bootstrap. In addition, adding different settings to the knife.rb file will be covered, for people looking to expand the usage of knife and knife bootstrap. Most of this information is covered in higher detail in the main knife bootstrap page, as well as all the other options. You can check that page out using the reference here.<ref>[http://docs.chef.io/knife_bootstrap.html Knife Boostrap]</ref>

'''--bootstrap-curl-options OPTIONS, --bootstrap-install-command COMMAND, --bootstrap-install-sh URL'''

These commands allow customization of the installation bootstrap performs. They are all mutually exclusive, but allow different ways to perform this customization. The first, bootstap-curl-options, which allows additional cURL options to be performed alongside the bootstrap installation. To learn more about cURL, check out their main web page [http://curl.haxx.se/ here (cURL Home Page)].

== References ==
<references/>

CSC/ECE 517 Spring 2015/ch1a 2 WA

2015-02-09T20:30:41Z

Wpgallih:

Knife

Knife is the command line tool for managing Chef nodes. Simply, Chef allows the distribution of server environments between many different servers (called '''nodes'''). Any changes to the primary chef server (called the '''chef repo''' are distributed throughout all the other nodes, while different nodes can have other recipes and send them back to the chef repo. Knife, then, handles the communication between nodes and the chef repo. For example, let's say that there is an object on the chef repo that a node desires. Knife provides the tools to download that object to the node. Knife also allows setting up a node, installing necessary packages, management of users, and much more.

== Background ==

Chef streamlines the task of configuring and maintaining a company's servers, and can integrate with cloud-based platforms.
If you are unfamiliar with Chef and how it works, check out the comparison between Chef and Puppet here: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/ch1_1w10_ga] or take a look at the official Chef website here: <ref>[https://www.chef.io/ Chef]</ref>. There, a deeper understanding of Chef can be attained.

Chef includes two important command-line tools.
*Knife command-line tool
*Chef command-line tool

knife is the command-line tool that provides an interface between a local chef-repo and the Chef server. Whereas, Chef command-line tool is used while working with the chef repo.

<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:chef_knife server.png]]</div>

== Examples ==

Using Knife is fairly straightforward, with usage following this syntax:

<pre> knife [verb] [object] [options] </pre>

The different verbs, or subcommands, for Knife are as follows, from the Using Knife page<ref> [https://docs.chef.io/knife_using.html Knife Documents]</ref>: bootstrap, client, configure, cookbook, cookbook site, data bag, delete, deps, diff, download, edit, environment, exec, index rebuild, list, node, recipe list, role, search, show, ssh, status, tag, upload, user, and xargs.

'''Warning:''' Before you run many of these commands, you should have the knife editor set correctly. In the chef-repo, there are multiple ruby files that set the configuration of the environment. Inside of knife.rb, you need to add or set the following line.

<pre>
<syntaxhighlight lang="ruby">
knife[:editor] = "/usr/bin/vim"
</syntaxhighlight>
</pre>

The path can be set to the text editor of choice, the above command sets the editor to vim.

The example we will use is also one that is useful for setting up nodes, and that is the usage of the bootstrap command. To set up a node, go to the command line on the chef repo and execute the following command:

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo </pre>

First, the verb used is '''bootstrap'''. Bootstrap is the subcommand that allows the installation of a chef client on to a targeted node.
Second, the object is the ip_address_of_node. Every subcommand takes an object, and since chef operates on many ruby principles and scripts, the object can be most anything. For boostrap, this object is the ip of the server address. For other commands, this might be something different.
Third, we have the options for the bootstrap command and the object. For bootstrap, this includes the username and password for the node, and the option --sudo, to make sure all commands are executed correctly.

Before we do the next example, let's cover an important part of object strings and how they are treated by knife and the chef repo.

'''Wildcards'''
A wildcard search can be used similar to standard regex commands, with one notable difference. The wildcard character itself '''must be escaped using the \ character.''' Here is an example from the "Using Knife" page on the chef website. Let's say the following was used to search for an object:

<pre>data_bags/a\*</pre>

Will return all of the objects that start with data_bags\a on the chef-node. However, if we were to run the following:

<pre>data_bags/a*</pre>

Will only search for objects on the chef repo corresponding to objects starting with data_bags/a on the node. Therefore, the * was applied '''before''' being sent to the chef repo, instead of after. So, as an example, let us list all of the data bags that are on the server that start with 'a'. Our object, then, is the string above, <code>data_bags/a\*</code>. The verb that lists different objects on the chef repo is called <code>list</code>. Our command we would run would be this:

<pre>knife list data_bags/a\*</pre>

Which would print to the console all of the objects in the data_bags directory that started with a.

== Bootstrapping A Node ==

One of the key uses of knife is doing something called "bootstrapping" a node <ref>[http://docs.chef.io/open_source/install_bootstrap.html Install Bootstrap]</ref>. This key tool allows someone using the Chef server to set up a remote node, or client. Not only does knife set up all of the relevant recipes, environments, and other such things related with the chef repo itself, it also installs all of the tools necessary for interacting with the chef server and configuring the chef client. Because of this, a basic understanding in how to bootstrap a node, and some knowledge on the available options for bootstrapping a node, is important.

Luckily, bootstrapping a node is very simple. To bootstrap a node, the general command would look like this. Be aware, this is being run from the chef server.

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo --node-name name_of_node</pre>

This process will create a chef client at the designated IP adress. The username and the password is the username and password of a root access user on the remote node. The name of the node can be set here as well, instead of automatically using other settings. The option is shown here, to make the rest of the example easier to understand. Luckily, the knife bootstrap command uses an omnibus installer that automatically detects the OS of the target machine and will install all of the necessary command line tools and internal installations, like ruby, for the chef client to function. Once the bootstrap command is complete, the following message will be displayed.
<pre>INFO: Report handlers complete</pre>

However, before continuing, confirmation of the remote node is necessary. To confirm that the remote node was installed correctly and is running, run the following command.

<pre>knife client show name_of_node</pre>

Here, the name_of_node is the name of the node either set in other options and commands, such as the --node-name used above. When this is run, the node's information should be displayed, such as if the node is an admin, the name of the node, and the JSON type it was created from.

<pre>admin: false
chef_type: client
json_class: Chef::ApiClient
name: name_of_node
public_key:</pre>

== Bootstrap Options and Knife Settings ==
As one of the most powerful tools knife has to offer, the bootstrap function has many different options available to it. The "Installing Bootstrap" section covered three such options (-x, -P, and --node-name), but there are many more available that are useful. Here are a few that stand out as being useful to someone using knife bootstrap for the first time, or for people who are dealing with something outside of the normal conditions for installing and using knife bootstrap. In addition, adding different settings to the knife.rb file will be covered, for people looking to expand the usage of knife and knife bootstrap. Most of this information is covered in higher detail in the main knife bootstrap page, as well as all the other options. You can check that page out using the reference here.<ref>[http://docs.chef.io/knife_bootstrap.html Knife Boostrap]</ref>

== References ==
<references/>

CSC/ECE 517 Spring 2015/ch1a 2 WA

2015-02-09T20:18:34Z

Wpgallih:

Knife

Knife is the command line tool for managing Chef nodes. Simply, Chef allows the distribution of server environments between many different servers (called '''nodes'''). Any changes to the primary chef server (called the '''chef repo''' are distributed throughout all the other nodes, while different nodes can have other recipes and send them back to the chef repo. Knife, then, handles the communication between nodes and the chef repo. For example, let's say that there is an object on the chef repo that a node desires. Knife provides the tools to download that object to the node. Knife also allows setting up a node, installing necessary packages, management of users, and much more.

== Knife ==

== Background ==

Chef streamlines the task of configuring and maintaining a company's servers, and can integrate with cloud-based platforms.
If you are unfamiliar with Chef and how it works, check out the comparison between Chef and Puppet here: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/ch1_1w10_ga] or take a look at the official Chef website here: <ref>[https://www.chef.io/ Chef]</ref>. There, a deeper understanding of Chef can be attained.

Chef includes two important command-line tools.
*Knife command-line tool
*Chef command-line tool

knife is the command-line tool that provides an interface between a local chef-repo and the Chef server. Whereas, Chef command-line tool is used while working with the chef repo.

<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:chef_knife server.png]]</div>

== Examples ==

Using Knife is fairly straightforward, with usage following this syntax:

<pre> knife [verb] [object] [options] </pre>

The different verbs, or subcommands, for Knife are as follows, from the Using Knife page<ref> [https://docs.chef.io/knife_using.html Knife Documents]</ref>: bootstrap, client, configure, cookbook, cookbook site, data bag, delete, deps, diff, download, edit, environment, exec, index rebuild, list, node, recipe list, role, search, show, ssh, status, tag, upload, user, and xargs.

'''Warning:''' Before you run many of these commands, you should have the knife editor set correctly. In the chef-repo, there are multiple ruby files that set the configuration of the environment. Inside of knife.rb, you need to add or set the following line.

<pre>
<syntaxhighlight lang="ruby">
knife[:editor] = "/usr/bin/vim"
</syntaxhighlight>
</pre>

The path can be set to the text editor of choice, the above command sets the editor to vim.

The example we will use is also one that is useful for setting up nodes, and that is the usage of the bootstrap command. To set up a node, go to the command line on the chef repo and execute the following command:

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo </pre>

First, the verb used is '''bootstrap'''. Bootstrap is the subcommand that allows the installation of a chef client on to a targeted node.
Second, the object is the ip_address_of_node. Every subcommand takes an object, and since chef operates on many ruby principles and scripts, the object can be most anything. For boostrap, this object is the ip of the server address. For other commands, this might be something different.
Third, we have the options for the bootstrap command and the object. For bootstrap, this includes the username and password for the node, and the option --sudo, to make sure all commands are executed correctly.

Before we do the next example, let's cover an important part of object strings and how they are treated by knife and the chef repo.

'''Wildcards'''
A wildcard search can be used similar to standard regex commands, with one notable difference. The wildcard character itself '''must be escaped using the \ character.''' Here is an example from the "Using Knife" page on the chef website. Let's say the following was used to search for an object:

<pre>data_bags/a\*</pre>

Will return all of the objects that start with data_bags\a on the chef-node. However, if we were to run the following:

<pre>data_bags/a*</pre>

Will only search for objects on the chef repo corresponding to objects starting with data_bags/a on the node. Therefore, the * was applied '''before''' being sent to the chef repo, instead of after. So, as an example, let us list all of the data bags that are on the server that start with 'a'. Our object, then, is the string above, <code>data_bags/a\*</code>. The verb that lists different objects on the chef repo is called <code>list</code>. Our command we would run would be this:

<pre>knife list data_bags/a\*</pre>

Which would print to the console all of the objects in the data_bags directory that started with a.

== Bootstrapping A Node ==

One of the key uses of knife is doing something called "bootstrapping" a node <ref>[http://docs.chef.io/open_source/install_bootstrap.html Install Bootstrap]</ref>. This key tool allows someone using the Chef server to set up a remote node, or client. Not only does knife set up all of the relevant recipes, environments, and other such things related with the chef repo itself, it also installs all of the tools necessary for interacting with the chef server and configuring the chef client. Because of this, a basic understanding in how to bootstrap a node, and some knowledge on the available options for bootstrapping a node, is important.

Luckily, bootstrapping a node is very simple. To bootstrap a node, the general command would look like this. Be aware, this is being run from the chef server.

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo --node-name name_of_node</pre>

This process will create a chef client at the designated IP adress. The username and the password is the username and password of a root access user on the remote node. The name of the node can be set here as well, instead of automatically using other settings. The option is shown here, to make the rest of the example easier to understand. Luckily, the knife bootstrap command uses an omnibus installer that automatically detects the OS of the target machine and will install all of the necessary command line tools and internal installations, like ruby, for the chef client to function. Once the bootstrap command is complete, the following message will be displayed.
<pre>INFO: Report handlers complete</pre>

However, before continuing, confirmation of the remote node is necessary. To confirm that the remote node was installed correctly and is running, run the following command.

<pre>knife client show name_of_node</pre>

Here, the name_of_node is the name of the node either set in other options and commands, such as the --node-name used above. When this is run, the node's information should be displayed, such as if the node is an admin, the name of the node, and the JSON type it was created from.

<pre>admin: false
chef_type: client
json_class: Chef::ApiClient
name: name_of_node
public_key:</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/ch1a 2 WA

2015-02-09T20:14:13Z

Wpgallih:

Knife

Knife is the command line tool for managing Chef nodes. Simply, Chef allows the distribution of server environments between many different servers (called '''nodes'''). Any changes to the primary chef server (called the '''chef repo''' are distributed throughout all the other nodes, while different nodes can have other recipes and send them back to the chef repo. Knife, then, handles the communication between nodes and the chef repo. For example, let's say that there is an object on the chef repo that a node desires. Knife provides the tools to download that object to the node. Knife also allows setting up a node, installing necessary packages, management of users, and much more.

== Knife ==

== Background ==

Chef streamlines the task of configuring and maintaining a company's servers, and can integrate with cloud-based platforms.
If you are unfamiliar with Chef and how it works, check out the comparison between Chef and Puppet here: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/ch1_1w10_ga] or take a look at the official Chef website here: <ref>[https://www.chef.io/ Chef]</ref>. There, a deeper understanding of Chef can be attained.

Chef includes two important command-line tools.
*Knife command-line tool
*Chef command-line tool

knife is the command-line tool that provides an interface between a local chef-repo and the Chef server. Whereas, Chef command-line tool is used while working with the chef repo.

<div class="center" style="width: auto; margin-left: auto; margin-right: auto;"> [[File:chef_knife server.png]]</div>

== Examples ==

Using Knife is fairly straightforward, with usage following this syntax:

<pre> knife [verb] [object] [options] </pre>

The different verbs, or subcommands, for Knife are as follows, from the Using Knife page<ref> [https://docs.chef.io/knife_using.html Knife Documents]</ref>: bootstrap, client, configure, cookbook, cookbook site, data bag, delete, deps, diff, download, edit, environment, exec, index rebuild, list, node, recipe list, role, search, show, ssh, status, tag, upload, user, and xargs.

'''Warning:''' Before you run many of these commands, you should have the knife editor set correctly. In the chef-repo, there are multiple ruby files that set the configuration of the environment. Inside of knife.rb, you need to add or set the following line.

<pre>
<syntaxhighlight lang="ruby">
knife[:editor] = "/usr/bin/vim"
</syntaxhighlight>
</pre>

The path can be set to the text editor of choice, the above command sets the editor to vim.

The example we will use is also one that is useful for setting up nodes, and that is the usage of the bootstrap command. To set up a node, go to the command line on the chef repo and execute the following command:

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo </pre>

First, the verb used is '''bootstrap'''. Bootstrap is the subcommand that allows the installation of a chef client on to a targeted node.
Second, the object is the ip_address_of_node. Every subcommand takes an object, and since chef operates on many ruby principles and scripts, the object can be most anything. For boostrap, this object is the ip of the server address. For other commands, this might be something different.
Third, we have the options for the bootstrap command and the object. For bootstrap, this includes the username and password for the node, and the option --sudo, to make sure all commands are executed correctly.

Before we do the next example, let's cover an important part of object strings and how they are treated by knife and the chef repo.

'''Wildcards'''
A wildcard search can be used similar to standard regex commands, with one notable difference. The wildcard character itself '''must be escaped using the \ character.''' Here is an example from the "Using Knife" page on the chef website. Let's say the following was used to search for an object:

<pre>data_bags/a\*</pre>

Will return all of the objects that start with data_bags\a on the chef-node. However, if we were to run the following:

<pre>data_bags/a*</pre>

Will only search for objects on the chef repo corresponding to objects starting with data_bags/a on the node. Therefore, the * was applied '''before''' being sent to the chef repo, instead of after. So, as an example, let us list all of the data bags that are on the server that start with 'a'. Our object, then, is the string above, <code>data_bags/a\*</code>. The verb that lists different objects on the chef repo is called <code>list</code>. Our command we would run would be this:

<pre>knife list data_bags/a\*</pre>

Which would print to the console all of the objects in the data_bags directory that started with a.

== Bootstrapping A Node ==

One of the key uses of knife is doing something called "bootstrapping" a node. This key tool allows someone using the Chef server to set up a remote node, or client. Not only does knife set up all of the relevant recipes, environments, and other such things related with the chef repo itself, it also installs all of the tools necessary for interacting with the chef server and configuring the chef client. Because of this, a basic understanding in how to bootstrap a node, and some knowledge on the available options for bootstrapping a node, is important.

Luckily, bootstrapping a node is very simple. To bootstrap a node, the general command would look like this. Be aware, this is being run from the chef server.

<pre>knife bootstrap ip_address_of_node -x username -P password --sudo --node-name name_of_node</pre>

This process will create a chef client at the designated IP adress. The username and the password is the username and password of a root access user on the remote node. The name of the node can be set here as well, instead of automatically using other settings. The option is shown here, to make the rest of the example easier to understand. Luckily, the knife bootstrap command uses an omnibus installer that automatically detects the OS of the target machine and will install all of the necessary command line tools and internal installations, like ruby, for the chef client to function. Once the bootstrap command is complete, the following message will be displayed.
<pre>INFO: Report handlers complete</pre>

However, before continuing, confirmation of the remote node is necessary. To confirm that the remote node was installed correctly and is running, run the following command.

<pre>knife client show name_of_node</pre>

Here, the name_of_node is the name of the node either set in other options and commands, such as the --node-name used above. When this is run, the node's information should be displayed, such as if the node is an admin, the name of the node, and the JSON type it was created from.

<pre>admin: false
chef_type: client
json_class: Chef::ApiClient
name: name_of_node
public_key:</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015

2015-02-09T19:24:24Z

Wpgallih:

*[[CSC/ECE 517 Spring 2015/ch1a 17 WL]]
*[[CSC/ECE 517 Spring 2015/ch1a 5 ZX]]
*[[CSC/ECE 517 Spring 2015/ch1a 6 TZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 4 RW]]
*[[CSC/ECE 517 Spring 2015/ch1a 7 SA]]
*[[CSC/ECE 517 Spring 2015/ch1a 9 RA]]
*[[CSC/ECE 517 Spring 2015/ch1a 14 RI]]
*[[CSC/ECE 517 Spring 2015/ch1a 1 DZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 20 HA]]
*[[CSC/ECE 517 Spring 2015/ch1a 3 RF]]
*[[CSC/ECE 517 Spring 2015/ch1a 12 LS]]
*[[CSC/ECE 517 Spring 2015/ch1a 13 MA]]
*[[CSC/ECE 517 Spring 2015/ch1a 2 WA]]

CSC/ECE 517 Spring 2015/ch1a 2 WA

2015-02-03T02:39:07Z

Wpgallih:

== Knife ==

== Background ==

Knife is the command line tool for managing Chef nodes. If you are unfamiliar with Chef and how it works, check out the comparison between Chef and Puppet here: [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/ch1_1w10_ga] or take a look at the official Chef website here: [https://www.chef.io/]. There, a deeper understanding of Chef can be attained. Simply, Chef allows the distribution of server environments between many different servers (called '''nodes'''). Any changes to the primary chef server (called the '''chef repo''' are distributed throughout all the other nodes, while different nodes can have other recipes and send them back to the chef repo. Knife, then, handles the communication between nodes and the chef repo. For example, let's say that there is an object on the chef repo that a node desires. Knife provides the tools to download that object to the node. Knife also allows setting up a node, installing necessary packages, management of users, and much more.

== Examples ==

Using Knife is fairly straightforward, with usage following this syntax:

<code> knife [verb] [object] [options] </code>

The different verbs, or subcommands, for Knife are as follows, from the Using Knife page [https://docs.chef.io/knife_using.html]: bootstrap, client, configure, cookbook, cookbook site, data bag, delete, deps, diff, download, edit, environment, exec, index rebuild, list, node, recipe list, role, search, show, ssh, status, tag, upload, user, and xargs.

'''Warning:''' Before you run many of these commands, you should have the knife editor set correctly. In the chef-repo, there are multiple ruby files that set the configuration of the environment. Inside of knife.rb, you need to add or set the following line.

<syntaxhighlight lang="ruby">
knife[:editor] = "/usr/bin/vim"
</syntaxhighlight>

The path can be set to the text editor of choice, the above command sets the editor to vim.

The example we will use is also one that is useful for setting up nodes, and that is the usage of the bootstrap command. To set up a node, go to the command line on the chef repo and execute the following command:

<code>knife bootstrap ip_address_of_node -x username -P password --sudo </code>

First, the verb used is '''bootstrap'''. Bootstrap is the subcommand that allows the installation of a chef client on to a targeted node.
Second, the object is the ip_address_of_node. Every subcommand takes an object, and since chef operates on many ruby principles and scripts, the object can be most anything. For boostrap, this object is the ip of the server address. For other commands, this might be something different.
Third, we have the options for the bootstrap command and the object. For bootstrap, this includes the username and password for the node, and the option --sudo, to make sure all commands are executed correctly.

Before we do the next example, let's cover an important part of object strings and how they are treated by knife and the chef repo.

'''Wildcards'''
A wildcard search can be used similar to standard regex commands, with one notable difference. The wildcard character itself '''must be escaped using the \ character.''' Here is an example from the "Using Knife" page on the chef website. Let's say the following was used to search for an object:

<code>data_bags/a\*</code>

Will return all of the objects that start with data_bags\a on the chef-node. However, if we were to run the following:

<code>data_bags/a*</code>

Will only search for objects on the chef repo corresponding to objects starting with data_bags/a on the node. Therefore, the * was applied '''before''' being sent to the chef repo, instead of after. So, as an example, let us list all of the data bags that are on the server that start with 'a'. Our object, then, is the string above, <code>data_bags/a\*</code>. The verb that lists different objects on the chef repo is called <code>list</code>. Our command we would run would be this:

<code>knife list data_bags/a\*</code>

Which would print to the console all of the objects in the data_bags directory that started with a.

CSC/ECE 517 Spring 2015/ch1a 2 WA

2015-02-03T01:52:12Z

Wpgallih:

CSC/ECE 517 Spring 2015/ch1a 2 WA

2015-02-03T01:17:16Z

Wpgallih: Created page with " == Knife == Background Knife is the command line tool for managing Chef nodes. If you are unfamiliar with Chef and how it works, check out the comparison between Chef and Pu..."

== Knife ==
[[Background]]
Knife is the command line tool for managing Chef nodes. If you are unfamiliar with Chef and how it works, check out the comparison between Chef and Puppet [[http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2013/ch1_1w10_ga]]