Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:58:14Z

Sanaik2: /* Proposed Test Cases */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
About Servo<ref> https://www.mozilla.org/en-US/research/projects/</ref>
 
Servo is an project to build a Web browser engine for a new generation of hardware. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.
 
About Rust<ref>http://en.wikipedia.org/wiki/Rust_%28programming_language%29</ref>
 
The goal of Rust is to be a good language for the creation of large client and server programs that run over the Internet. This has led to a feature set with an emphasis on safety, control of memory layout and concurrency. Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable to C++ code that manually takes precautions comparable to what the Rust language mandates.
 
Purpose
 
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a [https://github.com/servo/servo Servo] engine. It is basically a prototype web browser engine written in the [https://github.com/rust-lang/rust Rust] language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.

*Each box represents a Rust task.

*Primary tasks are the ones which are represented by blue boxes.

*Gray boxes are for auxiliary tasks.

*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.

*Supervisor relationships are shown by dashed lines.

*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the [http://en.wikipedia.org/wiki/MIME MIME] sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using [http://en.wikipedia.org/wiki/Singleton_pattern "Singleton Pattern"] because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using [http://en.wikipedia.org/wiki/Adapter_pattern "Adapter Pattern"] to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

==Proposed Test Cases==

*Validating the url used to create a websocket object.

*Check for an explicit port.

*Checking if the connection with the remote server is established.

*Check with session variables are reset on creating a new connection.

*Check if the data if the messages are delivered to the remote host.

*When the user agent validates the server's response during the "establish a WebSocket connection" algorithm, if the status code received from the server is not 101 (e.g. it is a redirect), it must fail the WebSocket connection.

==Appendix==

*Steps used for [https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust Installing Rust].

*Steps used for [https://github.com/servo/servo Building Servo].

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:55:16Z

Sanaik2: /* Proposed Test Cases */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
About Servo<ref> https://www.mozilla.org/en-US/research/projects/</ref>
 
Servo is an project to build a Web browser engine for a new generation of hardware. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.
 
About Rust<ref>http://en.wikipedia.org/wiki/Rust_%28programming_language%29</ref>
 
The goal of Rust is to be a good language for the creation of large client and server programs that run over the Internet. This has led to a feature set with an emphasis on safety, control of memory layout and concurrency. Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable to C++ code that manually takes precautions comparable to what the Rust language mandates.
 
Purpose
 
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a [https://github.com/servo/servo Servo] engine. It is basically a prototype web browser engine written in the [https://github.com/rust-lang/rust Rust] language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.

*Each box represents a Rust task.

*Primary tasks are the ones which are represented by blue boxes.

*Gray boxes are for auxiliary tasks.

*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.

*Supervisor relationships are shown by dashed lines.

*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the [http://en.wikipedia.org/wiki/MIME MIME] sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using [http://en.wikipedia.org/wiki/Singleton_pattern "Singleton Pattern"] because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using [http://en.wikipedia.org/wiki/Adapter_pattern "Adapter Pattern"] to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

==Proposed Test Cases==

*Validating the url used to create a websocket object.

*Checking if the connection with the remote server is established.

*Check with session variables are reset on creating a new connection.

*Check if the data if the messages are delivered to the remote host.

*When the user agent validates the server's response during the "establish a WebSocket connection" algorithm, if the status code received from the server is not 101 (e.g. it is a redirect), it must fail the WebSocket connection.

==Appendix==

-Steps used for [https://github.com/rust-lang/rust/wiki/Note-getting-started-developing-Rust Installing Rust].

-Steps used for [https://github.com/servo/servo Building Servo].

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:28:37Z

Sanaik2: /* Introduction */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
About Servo<ref> https://www.mozilla.org/en-US/research/projects/</ref>
 
Servo is an project to build a Web browser engine for a new generation of hardware. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.
 
About Rust<ref>http://en.wikipedia.org/wiki/Rust_%28programming_language%29</ref>
 
The goal of Rust is to be a good language for the creation of large client and server programs that run over the Internet. This has led to a feature set with an emphasis on safety, control of memory layout and concurrency. Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable to C++ code that manually takes precautions comparable to what the Rust language mandates.
 
Purpose
 
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a [https://github.com/servo/servo Servo] engine. It is basically a prototype web browser engine written in the [https://github.com/rust-lang/rust Rust] language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the [http://en.wikipedia.org/wiki/MIME MIME] sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using [http://en.wikipedia.org/wiki/Singleton_pattern "Singleton Pattern"] because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using [http://en.wikipedia.org/wiki/Adapter_pattern "Adapter Pattern"] to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:27:34Z

Sanaik2: /* Introduction */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
About Servo<ref> https://www.mozilla.org/en-US/research/projects/</ref>
 
Servo is an project to build a Web browser engine for a new generation of hardware. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.
 
About Rust<ref>http://en.wikipedia.org/wiki/Rust_%28programming_language%29</ref>
 
The goal of Rust is to be a good language for the creation of large client and server programs that run over the Internet.[16] This has led to a feature set with an emphasis on safety, control of memory layout and concurrency. Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable to C++ code that manually takes precautions comparable to what the Rust language mandates.
 
Purpose
 
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a [https://github.com/servo/servo Servo] engine. It is basically a prototype web browser engine written in the [https://github.com/rust-lang/rust Rust] language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the [http://en.wikipedia.org/wiki/MIME MIME] sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using [http://en.wikipedia.org/wiki/Singleton_pattern "Singleton Pattern"] because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using [http://en.wikipedia.org/wiki/Adapter_pattern "Adapter Pattern"] to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:27:17Z

Sanaik2: /* Introduction */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
About Servo<ref> https://www.mozilla.org/en-US/research/projects/</ref>
 
Servo is an project to build a Web browser engine for a new generation of hardware. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.
 
About Rust<ref>http://en.wikipedia.org/wiki/Rust_%28programming_language%29</ref>
 
The goal of Rust is to be a good language for the creation of large client and server programs that run over the Internet.[16] This has led to a feature set with an emphasis on safety, control of memory layout and concurrency. Performance of safe code is expected to be slower than C++ if performance is the only consideration, but to be comparable to C++ code that manually takes precautions comparable to what the Rust language mandates.
Purpose
 
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a [https://github.com/servo/servo Servo] engine. It is basically a prototype web browser engine written in the [https://github.com/rust-lang/rust Rust] language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the [http://en.wikipedia.org/wiki/MIME MIME] sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using [http://en.wikipedia.org/wiki/Singleton_pattern "Singleton Pattern"] because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using [http://en.wikipedia.org/wiki/Adapter_pattern "Adapter Pattern"] to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:21:22Z

Sanaik2: /* Introduction */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
About Servo<ref> https://www.mozilla.org/en-US/research/projects/</ref>
 
Servo is an project to build a Web browser engine for a new generation of hardware. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.
 
Purpose
 
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a [https://github.com/servo/servo Servo] engine. It is basically a prototype web browser engine written in the [https://github.com/rust-lang/rust Rust] language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the [http://en.wikipedia.org/wiki/MIME MIME] sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using [http://en.wikipedia.org/wiki/Singleton_pattern "Singleton Pattern"] because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using [http://en.wikipedia.org/wiki/Adapter_pattern "Adapter Pattern"] to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:20:42Z

Sanaik2: /* Introduction */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
About Servo<ref> https://www.mozilla.org/en-US/research/projects/</ref>
Servo is an project to build a Web browser engine for a new generation of hardware. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.
 
Purpose
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a [https://github.com/servo/servo Servo] engine. It is basically a prototype web browser engine written in the [https://github.com/rust-lang/rust Rust] language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the [http://en.wikipedia.org/wiki/MIME MIME] sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using [http://en.wikipedia.org/wiki/Singleton_pattern "Singleton Pattern"] because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using [http://en.wikipedia.org/wiki/Adapter_pattern "Adapter Pattern"] to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:08:17Z

Sanaik2: /* Design patterns */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a [https://github.com/servo/servo Servo] engine. It is basically a prototype web browser engine written in the [https://github.com/rust-lang/rust Rust] language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the [http://en.wikipedia.org/wiki/MIME MIME] sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using [http://en.wikipedia.org/wiki/Singleton_pattern "Singleton Pattern"] because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using [http://en.wikipedia.org/wiki/Adapter_pattern "Adapter Pattern"] to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:07:09Z

Sanaik2: /* Requirement analysishttps://github.com/servo/servo/wiki/WebSocket-student-project */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a [https://github.com/servo/servo Servo] engine. It is basically a prototype web browser engine written in the [https://github.com/rust-lang/rust Rust] language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the [http://en.wikipedia.org/wiki/MIME MIME] sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:06:06Z

Sanaik2: /* Introduction */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a [https://github.com/servo/servo Servo] engine. It is basically a prototype web browser engine written in the [https://github.com/rust-lang/rust Rust] language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:03:15Z

Sanaik2: /* Proposed Test Cases */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:03:00Z

Sanaik2: /* UML diagram: UseCase Diagram */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object:
This object allows a basic connection to the server.
 
*Call the onopen function:
Connection along with on open event.
 
*Call the onclose function:
Connection along with on close event.
 
*Call the onmessage function:
Receiving of simple data and the on message event.
 
*Call the send function:
Sends fragmented data.

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T02:02:19Z

Sanaik2: /* UML diagram: UseCase Diagram */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
*Create a web socket object.
This object allows a basic connection to the server.
 
*Call the onopen function.
Connection along with on open event.
 
*Call the onclose function.
Connection along with on close event.
 
*Call the onmessage function.
Receiving of simple data and the on message event.
 
*Call the send function.
Sends fragmented data.

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T01:57:30Z

Sanaik2: /* UML diagram: UseCase Diagram */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]
 
Use Cases:
 
Create a web socket object.
This allows a basic connection to the server.

Call the onopen function.
Call the onclose function.
Call the onmessage function.
Call the send function.

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T01:53:49Z

Sanaik2: /* UML diagrams (Eg use case diagram, class diagrams) */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagram: UseCase Diagram ==
[[File:UseCaseDiagram_websocket.png]]

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T01:50:32Z

Sanaik2: /* Data and component design */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
Flowchart:
 
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:UseCaseDiagram_websocket.png]]

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T01:47:35Z

Sanaik2: /* Data and component design */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
[[File:Workflow.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:UseCaseDiagram_websocket.png]]

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T01:46:12Z

Sanaik2: /* Data and component design */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
[[File:Diagram_websocket.jpg]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:UseCaseDiagram_websocket.png]]

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T01:45:55Z

Sanaik2: /* Data and component design */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
[[File:Diagram_websocket.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:UseCaseDiagram_websocket.png]]

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T01:44:37Z

Sanaik2: /* Data and component design */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
[[File:wfws.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:UseCaseDiagram_websocket.png]]

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T01:40:26Z

Sanaik2: /* Data and component design */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
[[File:WorkflowDiagram_websocket.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:UseCaseDiagram_websocket.png]]

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T01:38:34Z

Sanaik2: /* Data and component design */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==
[[File:WokflowDiagram_websocket.png]]

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:UseCaseDiagram_websocket.png]]

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-12T01:37:09Z

Sanaik2: /* UML diagrams (Eg use case diagram, class diagrams) */

This wiki page contains details on the planned course of actions for the project on [https://github.com/servo/servo/wiki/WebSocket-student-project Implement WebSocket API] for the Mozilla research project [http://github.com/servo/servo/wiki/Design Servo].

== Introduction ==
This project is about implementing a protocol to define rules regarding the nature of data being sent/receive between the web page and the server built on a Mozilla Framework. We started by creating a WebSocket interface and its corresponding Rust implementation. The constructor of this interface returns a WebSocket object which will help us in establishing a basic HTTP connection to the server. Thereafter we plan to implement methods like close, open on the API along with the onopen and onclose events.

This WebSocket interface runs on a Servo engine. It is basically a prototype web browser engine written in the Rust language. It is currently developed on 64bit OS X and 64bit Linux. Servo is explicitly not aiming to create a full Web browser (except for demonstration and experimentation purposes). Rather it is focused on creating a
solid, embedded engine.

== Architecture of system <ref>https://github.com/servo/servo/wiki/Design#task-supervision-diagram</ref> ==

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

The above diagrams gives us an overview of the Servo's architecture.
*Each box represents a Rust task.
*Primary tasks are the ones which are represented by blue boxes.
*Gray boxes are for auxiliary tasks.
*White boxes are for worker tasks. Each such box represents several tasks, the precise number of which are decided by the workload.
*Supervisor relationships are shown by dashed lines.
*Communication channels are shown by solid lines.

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
*A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.

*The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.

*Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

=== Singleton Pattern ===
We are using "Singleton Pattern" because it will confine the instantiation of class 'WebSocket' to only one object. This ensures that the instance can be accessed from everywhere and hence provide a global point of access.

=== Adapter Pattern ===
We are using "Adapter Pattern" to convert the interface of class 'WebSocket' into another interface that the caller expects. "Adapter pattern" allows other classes with incompatible interfaces to work together with class 'WebSocket', which is solely responsible to enable Web applications to maintain bidirectional communications with server-side processes.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:UseCaseDiagram_websocket.png]]

== Proposed Test Cases ==

== References ==
<references/>

File:UseCaseDiagram websocket.png

2014-11-12T01:04:53Z

Sanaik2: uploaded a new version of "File:UseCaseDiagram websocket.png"

File:UseCaseDiagram websocket.png

2014-11-12T00:58:43Z

Sanaik2:

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T02:28:19Z

Sanaik2: /* Requirement analysishttps://github.com/servo/servo/wiki/WebSocket-student-project */

== Introduction and architecture of system ==

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
 
a. A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.
 
b. The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.
 
c. Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation
 

13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 

14. We have to implement closing of connection along with on open and inclose events.
 

15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T02:27:41Z

Sanaik2: /* Requirement analysishttps://github.com/servo/servo/wiki/WebSocket-student-project */

== Introduction and architecture of system ==

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
 
a. A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.
 
b. The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.
 
c. Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation
 
13. In order to allow writing more data to the existing socket connection, we plan to make the stream member in the BufferedResponse in rust-http public.
 
14. We have to implement closing of connection along with on open and inclose events.
 
15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T02:24:09Z

Sanaik2: /* Requirement analysis */

== Introduction and architecture of system ==

== Requirement analysis<ref>https://github.com/servo/servo/wiki/WebSocket-student-project</ref> ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
 
a. A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.
 
b. The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.
 
c. Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation
 
13. We need to make the stream member of the BufferedResponse in rust-http public to enable writing further data to the original connection socket.
 
14. We have to implement the open and close method for connection.
 
15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T02:22:22Z

Sanaik2: /* References */

== Introduction and architecture of system ==

== Requirement analysis ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project<ref>https://html.spec.whatwg.org/multipage/comms.html</ref>.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
 
a. A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.
 
b. The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.
 
c. Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation
 
13. We need to make the stream member of the BufferedResponse in rust-http public to enable writing further data to the original connection socket.
 
14. We have to implement the open and close method for connection.
 
15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T02:21:48Z

Sanaik2:

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T02:17:52Z

Sanaik2: /* Requirement analysis */

== Introduction and architecture of system ==

== Requirement analysis ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
 
a. A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.
 
b. The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.
 
c. Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation
 
13. We need to make the stream member of the BufferedResponse in rust-http public to enable writing further data to the original connection socket.
 
14. We have to implement the open and close method for connection.
 
15. Furthermore, we have to implement sending simple short strings that fit within a single frame, receiving simple data and sending fragmented payloads across multiple frames.

== Data and component design ==

== Design patterns ==

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T02:11:59Z

Sanaik2: /* Requirement analysis */

== Introduction and architecture of system ==

== Requirement analysis ==

1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server. There are couple of sub parts we will need here:
 
12 a. A ws scheme protocol handler (just as we have an http scheme protocol handler) that will implement the WS-specific parts of the connection process.
 
12 b. The ws protocol load method should transparently delegate the initial HTTP connection to http_loader::factory(); this way we do not need to duplicate the HTTP protocol code.
 
12 c. Using the same technique as the MIME sniffing project, the WS load method should intercept the response from the HTTP load. This will allow us to look at the HTTP response and verify the presence of the required Upgrade header as described in the spec before sending the connection results to the WebSocket implementation

== Data and component design ==

== Design patterns ==

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T02:05:56Z

Sanaik2: /* Requirement analysis */

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T02:05:41Z

Sanaik2: /* Requirement analysis */

== Introduction and architecture of system ==

== Requirement analysis ==
 
1. The initial step required downloading and building the Rust compiler. To install Rust on the machine, clone the Rust source code from Mozilla's repository on GitHub.
 

2. Then we had to build the rust compiler.
 

3. To build the servo, we cloned the source code into the local repository.
 

4. Then we created a WebSocket.webidl file in the /servo/components/script/dom/webidls/ directory. This file was added in order to create a new interface for the web socket.This interface is inherited from the EventTarget interface in servo.
 

5. We added several attributes and methods to the WebSocket.webidl file which we plan to execute during the course of the project.
 

6. We created a corresponding websocket.rs file in the /servo/components/script/dom/ directory. In this file we have currently created a constructor that takes a url as an argument. We have a stub function to return the url that is used for initializing the web socket object through the constructor.
 

7. We added The WebSocketTypeId to the struct in the eventtarget.rs file.
 

8. We added the websocket module that we created to the lib.rs file.
 

9. After making all the changes we build are changes into servo.
 

10. This was Part One of our project, which was a part of our OSS project.
 

11. Part Two is our final project and is an extension of our OSS project.
 

12. Now we will create a constructor which will return an WebSocket object and initiate a basic connection with the server.
 

== Data and component design ==

== Design patterns ==

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T01:46:34Z

Sanaik2:

== Introduction and architecture of system ==

== Requirement analysis ==

== Data and component design ==

== Design patterns ==

== UML diagrams (Eg use case diagram, class diagrams) ==

== Proposed Test Cases ==

CSC/ECE 517 Fall 2014/final design doc M1451 hsss

2014-11-11T01:45:43Z

Sanaik2: Created page with " == Introduction and architecture of system == == Requirement analysis == == Data and component design == == Design patterns == == UML diagrams (Eg u..."

== Introduction and architecture of system == 

== Requirement analysis == 

== Data and component design == 

== Design patterns == 

== UML diagrams (Eg use case diagram, class diagrams) == 

== Proposed Test Cases ==

CSC/ECE 517 Fall 2014

2014-11-11T01:42:47Z

Sanaik2:

*[[CSC/ECE_517_Fall_2014/sample_page]]
*[[CSC/ECE_517_Fall_2014/ch1a 22 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 19 mx]]
*[[CSC/ECE 517 Fall 2014/ch1a 3 zq]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 lf]]
*[[CSC/ECE 517 Fall 2014/ch1a 4 wl]]
*[[CSC/ECE 517 Fall 2014/ch1a a7 ch]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 rs]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 jf]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 os]]
*[[CSC/ECE 517 Fall 2014/ch1a 8 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 15 gs]]
*[[CSC/ECE 517 Fall 2014/ch1a 10 hu]]
*[[CSC/ECE 517 Fall 2014/ch1a 20 kv]]
*[[CSC/ECE 517 Fall 2014/ch1a 21 as]]
*[[CSC/ECE 517 Fall 2014/ch1a 24 sa]]
*[[CSC/ECE 517 Fall 2014/ch1a 26 sn]]
*[[CSC/ECE 517 Fall 2014/ch1a 6 rl]]
*[[CSC/ECE 517 Fall 2014/ch1a 2 ss]]
*[[CSC/ECE 517 Fall 2014/ch1a 16 av]]
*[[CSC/ECE 517 Fall 2014/ch1a 1 rm]]
*[[CSC/ECE 517 Fall 2014/ch1a 1 sj]]
*[[CSC/ECE 517 Fall 2014/ch1a 23 ss]]
*[[CSC/ECE 517 Fall 2014/ch1a 20 rn]]
*[[CSC/ECE 517 Fall 2014/ch1a 22 sp]]
*[[CSC/ECE 517 Fall 2014/oss M1454 rss]]

*[[CSC/ECE 517 Fall 2014/ch1a 26 gn]]

*[[CSC/ECE 517 Fall 2014/ch1a 13 va]]
*[[CSC/ECE 517 Fall 2014/ch1a 9 aa]]
*[[CSC/ECE 517 Fall 2014/ch1a 9 kn]]
*[[CSC/ECE 517 Fall 2014/ch1a 11 ap]]
*[[CSC/ECE 517 Fall 2014/ch1a 25 ks]]
*[[CSC/ECE 517 Fall 2014/ch1a 7 kz]]
*[[CSC/ECE_517_Fall_2014/ch1a_6_bn]]
*[[CSC/ECE_517_Fall_2014/ch1a 10 zz]]
*[[CSC/ECE_517_Fall_2014/ch1a 16 va]]
*[[CSC/ECE_517_Fall_2014/ch1a F1415 rv]]
*[[CSC/ECE_517_Fall_2014/ch1a_3_cp]]
*[[CSC/ECE 517 Fall 2014/ch1b 26 sa]]
*[[CSC/ECE_517_Fall_2014/ch1b_28_cg]]
*[[CSC/ECE_517_Fall_2014/ch1b 29 ry]]
*[[CSC/ECE_517_Fall_2014/ch1b 30 cs]]
*[[CSC/ECE_517_Fall_2014/ch1b_33_jy]]
*[[CSC/ECE_517_Fall_2014/ch1b_27_js]]
*[[CSC/ECE 517 Fall 2014/oss E1453 syy]]
*[[CSC/ECE 517 Fall 2014/oss E1463 vpd]]
*[[CSC/ECE 517 Fall 2014/oss E1465 oak]]
*[[CSC/ECE 517 Fall 2014/oss_M1456_kdv]]
*[[CSC/ECE 517 Fall 2014/oss_M1453_sst]]
*[[CSC/ECE 517 Fall 2014/oss_E1456_akk]]
*[[CSC/ECE_517_Fall_2014/oss_M1455_asa]]
*[[CSC/ECE_517_Fall_2014/oss_E1458_sst]]
*[[CSC/ECE_517_Fall_2014/oss_E1457_ags]]
*[[CSC/ECE_517_Fall_2014/OSS_E1466_gjf]]
*[[CSC/ECE_517_Fall_2014/oss_M1452_jns]]
*[[CSC/ECE_517_Fall_2014/oss_E1462_nms]]
*[[CSC/ECE_517_Fall_2014/OSS_S1455_ajp]]
*[[CSC/ECE_517_Fall_2014/OSS_S1454_ccc]]
*[[CSC/ECE_517_Fall_2014/OSS_E1450_cxm]]
*[[CSC/ECE_517_Fall_2014/OSS_E1455_skn]]
*[[CSC/ECE_517_Fall_2014/OSS_M1450_vda]]
*[[CSC/ECE_517_Fall_2014/OSS_E1467_rsv]]
*[[CSC/ECE_517_Fall_2014/OSS_E1464_vnn]]
*[[CSC/ECE 517 Fall 2014/OSS_M1451_ahs]]
*[[CSC/ECE 517 Fall 2014/OSS_E1451_las]]
*[[CSC/ECE 517 Fall 2014/OSS_E1461_knn]]
*[[CSC/ECE_517_Fall_2014/oss_E1460_aua]]
*[[CSC/ECE_517_Fall_2014/oss_E1459_jjr]]
*[[CSC/ECE_517_Fall_2014/final_E1474_akkn]]
*[[CSC/ECE_517_Fall_2014/final_E1472_gjfz]]
*[[CSC/ECE_517_Fall_2014/final_design_doc_M1451_hsss]]

File:Report1455.png

2014-10-29T02:35:25Z

Sanaik2: uploaded a new version of "File:Report1455.png"

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T02:34:37Z

Sanaik2: /* Run Tests */

== EVALUATE REPLACING C IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS Mozilla Project.
It required us to make changes to the Servo code base.

== Introduction to Rust==
Rust is a new programming language for developing reliable and efficient systems. It's designed to support concurrency and parallelism in building platforms that take full advantage of modern hardware. Its static type system is safe and expressive and it provides strong guarantees about isolation, concurrency execution and memory safety.

Rust combines powerful and flexible modern programming constructs with a clear performance model to make program efficiency predictable and manageable. One important way it achieves this is by allowing fine-grained control over memory allocation through contiguous records and stack allocation. This control is balanced with the absolute requirement of safety: Rust’s type system and runtime guarantee the absence of data races, buffer overflow, stack overflow or access to uninitialized or deallocated memory.

== Introduction to Servo==
Servo is an experimental project to build a Web browser engine for a new generation of hardware: mobile devices, multi-core processors and high-performance GPUs. With Servo, we are rethinking the browser at every level of the technology stack — from input parsing to page layout to graphics rendering — to optimize for power efficiency and maximum parallelism.

Servo builds on top of Rust to provide a secure and reliable foundation. Memory safety at the core of the platform ensures a high degree of assurance in the browser’s trusted computing base. Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from git using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:Shraddha1455.png]]

 

Building servo basically compiling the code along withthe dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In image_cache_task.rs , we have a fn decode which calls the load_from_memory fn in base.rs. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code arround this function call in imacge_cache_task.rs 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();.
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 
Once we made the above changes, we now need to rebuild the servo code base. For this we again follow the same steps as described in the build servo section.

== Run Tests ==
We tested images with different file formats and resolution using 
<pre>./mach run image_url</pre> 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line.
 
Further the tabulated results are reported below:
 
[[File:report1455.png]] 

== References ==
https://www.mozilla.org/en-US/research/projects/

== Further Reading==
https://people.mozilla.org/~roc/Samsung/MozillaRustAndServo.pdf

File:Report1455.png

2014-10-29T02:33:30Z

Sanaik2:

File:Shraddha1455.png

2014-10-29T02:21:45Z

Sanaik2:

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T02:21:02Z

Sanaik2: /* Steps of Implementation */

== EVALUATE REPLACING C IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS Mozilla Project.
It required us to make changes to the Servo code base.

== Introduction ==
Servo is an experimental web browser layout engine being developed by Mozilla Research for new generation hardware.
The project has a symbiotic relationship with the Rust programming language, in which it is being developed. Rust is a new programming language for developing reliable and efficient systems.

Servo currently depends on a lot of C libraries, because Rust equivalents did not exist when the project started.
We want to evaluate switching some of these to new Rust libraries that have been created.
This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from git using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:Shraddha1455.png]]

 

Building servo basically compiling the code along withthe dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In image_cache_task.rs , we have a fn decode which calls the load_from_memory fn in base.rs. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code arround this function call in imacge_cache_task.rs 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();.
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 
Once we made the above changes, we now need to rebuild the servo code base. For this we again follow the same steps as described in the build servo section.

== Run Tests ==
We tested images with different file formats and resolution using ./mach run image_url. 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line.
 
Further the tabulated results are reported below:

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T02:19:26Z

Sanaik2: /* Steps of Implementation */

== EVALUATE REPLACING C IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS Mozilla Project.
It required us to make changes to the Servo code base.

== Introduction ==
Servo is an experimental web browser layout engine being developed by Mozilla Research for new generation hardware.
The project has a symbiotic relationship with the Rust programming language, in which it is being developed. Rust is a new programming language for developing reliable and efficient systems.

Servo currently depends on a lot of C libraries, because Rust equivalents did not exist when the project started.
We want to evaluate switching some of these to new Rust libraries that have been created.
This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from git using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:bs14.png]]

 

Building servo basically compiling the code along withthe dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In image_cache_task.rs , we have a fn decode which calls the load_from_memory fn in base.rs. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code arround this function call in imacge_cache_task.rs 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 

== Run Tests ==
We tested images with different file formats and resolution using ./mach run image_url. 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line.
 
Further the tabulated results are reported below:

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T02:18:33Z

Sanaik2: /* Steps of Implementation */

== EVALUATE REPLACING C IMAGE & FONT LIBRARIES WITH RUST EQUIVALENTS ==
In this wiki we represent the steps followed in order to implement the taskes assigned under the the above OSS Mozilla Project.
It required us to make changes to the Servo code base.

== Introduction ==
Servo is an experimental web browser layout engine being developed by Mozilla Research for new generation hardware.
The project has a symbiotic relationship with the Rust programming language, in which it is being developed. Rust is a new programming language for developing reliable and efficient systems.

Servo currently depends on a lot of C libraries, because Rust equivalents did not exist when the project started.
We want to evaluate switching some of these to new Rust libraries that have been created.
This project involves rewriting the code that uses these libraries as well as taking measurements before and after to determine the costs involved.

== Aim ==
The aim of our project is display the time required by the decode function to decode images of different formats, e.g, jpeg, bmp, png, gif.

== Steps of Implementation ==
We implemented the following steps on our linux machine: 

'''• Build Servo''' 
1. We first need to clone the servo repository from git using the following command: 
<pre>
git clone https://www.github.com/servo/servo 
</pre>
 
[[File:Screen1M1455.png]]

 
Now we have a local copy of the servo codebase.
 
 

2. We build the servo using 
./mach build 
[[File:buildservo1455.png]]

 

Building servo basically compiling the code along withthe dependent libraries. 
3. Once our servo is built, we have to run a test in order to ensure the build was successful. This is done using the below command 
./mach run url 

[[File:M1455_3.png]] 
[[File:M1455_4.png]]

The above output shows that the html page was successfully launched by the servo browser. Thus proving that the build was successful.
 
 
'''• Add timing code''' 
Once the initial step is completed, our next task was to add timing code around the code block which performed decoding of images.
The decoding of images is performed in the https://github.com/servo/servo/blob/master/components/net/image_cache_task.rs rust file.

1. In image_cache_task.rs , we have a fn decode which calls the load_from_memory fn in base.rs. 
2. Image decoding is implemented in this load_from_memory function. 
3. So we added the timing code arround this function call in imacge_cache_task.rs 
4. precise_time_ns() gives us the current time. 
5. So we added it before the call to get the start time of decoding and after the call to get the end time. 
6. Difference of the two gave us the decoding time, which can be printed on command line. 
<pre>let start_time=precise_time_ns();
let image = load_from_memory(data.as_slice());
let end_time=precise_time_ns();
let required_time=(end_time-start_time) as f64/1000000f64;</pre>

'''• Rebuild Servo''' 

== Run Tests ==
We tested images with different file formats and resolution using ./mach run image_url. 
[[File:M1455_5.png]] 
You can see the decoding time values reported for the different images on the command line.
These are the results we got:

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T02:17:52Z

Sanaik2: /* Steps of Implementation */

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T02:15:58Z

Sanaik2: /* Steps of Implementation */

File:Screen1M1455.png

2014-10-29T02:15:37Z

Sanaik2: uploaded a new version of "File:Screen1M1455.png"

File:Screen1M1455.png

2014-10-29T02:15:36Z

Sanaik2:

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T02:13:32Z

Sanaik2: /* Steps of Implementation */

CSC/ECE 517 Fall 2014/oss M1455 asa

2014-10-29T02:13:00Z

Sanaik2: /* Run Tests */