CSC/ECE 517 Spring 2015 M1503 EDTS - Revision history

Hsvalava: /* Class Diagram */

2015-05-05T16:59:58Z

Class Diagram

← Older revision		Revision as of 16:59, 5 May 2015
Line 249:		Line 249:
	Traits can be used in a manner similar to interfaces in a language like C++ or Java.		Traits can be used in a manner similar to interfaces in a language like C++ or Java.

	[[File:actors2.~~jpg~~]]		[[File:actors2.png]]

	===='''Sequence Diagram'''====		===='''Sequence Diagram'''====

Hsvalava: /* Class Diagram */

2015-05-05T16:59:46Z

Class Diagram

← Older revision		Revision as of 16:59, 5 May 2015
Line 249:		Line 249:
	Traits can be used in a manner similar to interfaces in a language like C++ or Java.		Traits can be used in a manner similar to interfaces in a language like C++ or Java.

	[[File:~~uml_actor~~.jpg]]		[[File:actors2.jpg]]

	===='''Sequence Diagram'''====		===='''Sequence Diagram'''====

Hsvalava: /* Class Diagram */

2015-05-05T16:55:33Z

Class Diagram

← Older revision		Revision as of 16:55, 5 May 2015
Line 249:		Line 249:
	Traits can be used in a manner similar to interfaces in a language like C++ or Java.		Traits can be used in a manner similar to interfaces in a language like C++ or Java.

	[[File:uml_actor.~~png‎~~]]		[[File:uml_actor.jpg]]

	===='''Sequence Diagram'''====		===='''Sequence Diagram'''====

Hsvalava: /* Class Diagram */

2015-05-05T16:52:18Z

Class Diagram

← Older revision		Revision as of 16:52, 5 May 2015
Line 249:		Line 249:
	Traits can be used in a manner similar to interfaces in a language like C++ or Java.		Traits can be used in a manner similar to interfaces in a language like C++ or Java.

	[[~~Fil~~:uml_actor.png‎]]		[[File:uml_actor.png‎]]

	===='''Sequence Diagram'''====		===='''Sequence Diagram'''====

Hsvalava at 16:49, 5 May 2015

2015-05-05T16:49:26Z

← Older revision		Revision as of 16:49, 5 May 2015
Line 249:		Line 249:
	Traits can be used in a manner similar to interfaces in a language like C++ or Java.		Traits can be used in a manner similar to interfaces in a language like C++ or Java.

	[[~~File~~:~~Class_diagram1~~.png‎]]		[[Fil:uml_actor.png‎]]

	===='''Sequence Diagram'''====		===='''Sequence Diagram'''====

	[[File:~~uml_actors~~.jpg]]		[[File:uml_seq1.jpg]]

	=='''Proposed Test Cases'''==		=='''Proposed Test Cases'''==

Hsvalava: /* Class Diagram */

2015-05-05T16:47:23Z

Class Diagram

← Older revision		Revision as of 16:47, 5 May 2015
Line 253:		Line 253:
	===='''Sequence Diagram'''====		===='''Sequence Diagram'''====

	[[File:~~uml_seq1~~.jpg]]		[[File:uml_actors.jpg]]

	=='''Proposed Test Cases'''==		=='''Proposed Test Cases'''==

Amohanr: /* Implementation */

2015-05-05T16:44:39Z

Implementation

← Older revision		Revision as of 16:44, 5 May 2015
Line 62:		Line 62:
	The following is a rough list of changes that will be required in the code to enable logging of HTTP messages. It includes adding types for HTTP request and response messages to the enum that represents messages exchanged between Servo and the debugger client. An "actor" is created to store the information that will be sent in these messages.		The following is a rough list of changes that will be required in the code to enable logging of HTTP messages. It includes adding types for HTTP request and response messages to the enum that represents messages exchanged between Servo and the debugger client. An "actor" is created to store the information that will be sent in these messages.
	*Add a NetworkEventMessage variant to the DevtoolsControlMsg enum in devtools_traits/lib.rs, containing fields for the request id and the network event.		*Add a NetworkEventMessage variant to the DevtoolsControlMsg enum in devtools_traits/lib.rs, containing fields for the request id and the network event.
	[[File:~~DevtoolsControlMsg~~.png]]		[[File:DevToolsControlMsg.png]]
	**DevtoolsControlMsg is a template type for the messages exchanged between the developer tools server and the actor objects. The developer tools server runs in a loop in the run_server function in devtools/lib.rs (this will be referred to as the "main loop" in run_server). The run_server function takes as arguments a sender and receiver, that can send and receive respectively messages of type <DevtoolsControlMsg>		**DevtoolsControlMsg is a template type for the messages exchanged between the developer tools server and the actor objects. The developer tools server runs in a loop in the run_server function in devtools/lib.rs (this will be referred to as the "main loop" in run_server). The run_server function takes as arguments a sender and receiver, that can send and receive respectively messages of type <DevtoolsControlMsg>
	**A new variant NetworkEventMessage of DevtoolsControlMsg will be used for all network event messages that are sent to the developer tools server. These messages will notify the server of either an HTTP request or an HTTP response.		**A new variant NetworkEventMessage of DevtoolsControlMsg will be used for all network event messages that are sent to the developer tools server. These messages will notify the server of either an HTTP request or an HTTP response.

Amohanr: /* Implementation */

2015-05-05T16:43:47Z

Implementation

← Older revision		Revision as of 16:43, 5 May 2015
Line 62:		Line 62:
	The following is a rough list of changes that will be required in the code to enable logging of HTTP messages. It includes adding types for HTTP request and response messages to the enum that represents messages exchanged between Servo and the debugger client. An "actor" is created to store the information that will be sent in these messages.		The following is a rough list of changes that will be required in the code to enable logging of HTTP messages. It includes adding types for HTTP request and response messages to the enum that represents messages exchanged between Servo and the debugger client. An "actor" is created to store the information that will be sent in these messages.
	*Add a NetworkEventMessage variant to the DevtoolsControlMsg enum in devtools_traits/lib.rs, containing fields for the request id and the network event.		*Add a NetworkEventMessage variant to the DevtoolsControlMsg enum in devtools_traits/lib.rs, containing fields for the request id and the network event.
			[[File:DevtoolsControlMsg.png]]
	**DevtoolsControlMsg is a template type for the messages exchanged between the developer tools server and the actor objects. The developer tools server runs in a loop in the run_server function in devtools/lib.rs (this will be referred to as the "main loop" in run_server). The run_server function takes as arguments a sender and receiver, that can send and receive respectively messages of type <DevtoolsControlMsg>		**DevtoolsControlMsg is a template type for the messages exchanged between the developer tools server and the actor objects. The developer tools server runs in a loop in the run_server function in devtools/lib.rs (this will be referred to as the "main loop" in run_server). The run_server function takes as arguments a sender and receiver, that can send and receive respectively messages of type <DevtoolsControlMsg>
	**A new variant NetworkEventMessage of DevtoolsControlMsg will be used for all network event messages that are sent to the developer tools server. These messages will notify the server of either an HTTP request or an HTTP response.		**A new variant NetworkEventMessage of DevtoolsControlMsg will be used for all network event messages that are sent to the developer tools server. These messages will notify the server of either an HTTP request or an HTTP response.
Line 77:		Line 78:
	**A message containing NetworkEvent::HttpResponse is sent with the response information after the load function receives the HTTP response. The values in the fields of the HttpResponse enum come from the information contained in the metadata struct. This response is tagged with the same ID value that was generated for its request earlier.		**A message containing NetworkEvent::HttpResponse is sent with the response information after the load function receives the HTTP response. The values in the fields of the HttpResponse enum come from the information contained in the metadata struct. This response is tagged with the same ID value that was generated for its request earlier.
	*Create a NetworkEventActor actor in the devtools crate that stores the request and response information transmitted in the new messages. The String field in the NetworkEventMessage contains a unique ID that joins the HTTPRequest and HTTPResponse. Associate the unique IDs with the corresponding NetworkEventActor names via a hashtable.		*Create a NetworkEventActor actor in the devtools crate that stores the request and response information transmitted in the new messages. The String field in the NetworkEventMessage contains a unique ID that joins the HTTPRequest and HTTPResponse. Associate the unique IDs with the corresponding NetworkEventActor names via a hashtable.
			[[File:NetworkEventActor.png]]
	**A new NetworkEventActor that implements the Actor trait is added to components/devtools/actors/. The NetworkEventActor needs to implement the name() and handle_message(..) functions of the Actor trait. The NetworkEventActor stores information about the HTTP requests and responses.		**A new NetworkEventActor that implements the Actor trait is added to components/devtools/actors/. The NetworkEventActor needs to implement the name() and handle_message(..) functions of the Actor trait. The NetworkEventActor stores information about the HTTP requests and responses.
	**A new NetworkEventActor object is created for each network event that is a new HTTP request. The corresponding response and updates should use the same actor object, which makes it possible for the debugger client to send query messages to the actor for more information (headers, cookies, security info, etc).		**A new NetworkEventActor object is created for each network event that is a new HTTP request. The corresponding response and updates should use the same actor object, which makes it possible for the debugger client to send query messages to the actor for more information (headers, cookies, security info, etc).

Amohanr: /* Actor Model */

2015-05-05T16:29:16Z

Actor Model

← Older revision		Revision as of 16:29, 5 May 2015
Line 214:		Line 214:
	Servo uses an actor-based devtools server implementation. There are different types of actor objects created to handle different messages. The developer tools server creates a ConsoleActor that is a part of every TabActor. The ConsoleActor is responsible for handling console events and sending messages of type ConsoleMsg to the debugger clients. As part of the initial steps of this project, we extended existing work that made console.log messages appear on the Web Console.		Servo uses an actor-based devtools server implementation. There are different types of actor objects created to handle different messages. The developer tools server creates a ConsoleActor that is a part of every TabActor. The ConsoleActor is responsible for handling console events and sending messages of type ConsoleMsg to the debugger clients. As part of the initial steps of this project, we extended existing work that made console.log messages appear on the Web Console.

	For the logging of Http requests and responses, a new NetworkEventActor that implements the Actor trait is added. This actor sends messages to, and listens for messages from, the debugger clients. We use the NetworkEventActor to store the request and response information that is to be transmitted in these messages. A unique id is used to keep track of a request and its corresponding response (as described in the Implementation section). In the event that a client ~~want~~ more information about a request/response, it can query the server using this unique id. Following is a code snippet showing the structure of the actor and its fields.		For the logging of Http requests and responses, a new NetworkEventActor that implements the Actor trait is added. This actor sends messages to, and listens for messages from, the debugger clients. We use the NetworkEventActor to store the request and response information that is to be transmitted in these messages. A unique id is used to keep track of a request and its corresponding response (as described in the Implementation section). In the event that a client wants more information about a request/response, it can query the server using this unique id. Following is a code snippet showing the structure of the actor and its fields.

	<pre>		<pre>

Hsvalava: /* Sender and Receiver */

2015-05-05T16:09:53Z

Sender and Receiver

← Older revision		Revision as of 16:09, 5 May 2015
Line 200:		Line 200:
	The sending half of the asynchronous channel type is Struct [https://doc.rust-lang.org/std/sync/mpsc/struct.Sender.html Sender<T>] and the receiving half is the struct [https://doc.rust-lang.org/std/sync/mpsc/struct.Receiver.html Receiver<T>].		The sending half of the asynchronous channel type is Struct [https://doc.rust-lang.org/std/sync/mpsc/struct.Sender.html Sender<T>] and the receiving half is the struct [https://doc.rust-lang.org/std/sync/mpsc/struct.Receiver.html Receiver<T>].
	For the purpose of this project, we will be using the channel to send and receive messages. To log the HTTP requests and responses on the console, we can use a variant of the enum 'DevtoolsControlMsg'. This enum is used to send messages to the devtools server to update its actors/state according to changes in the browser. We now add HTTPRequest and HHTPResponse variant to the DevtoolsControlMsg enum. We can now use the HTTP loaders' load function to send the HTTPRequest and HHTPResponse to the main loop in the run_server, where it can be received using a receiver. This is done by adding an argument, Sender<DevtoolsControlMsg> to the load function.		For the purpose of this project, we will be using the channel to send and receive messages. To log the HTTP requests and responses on the console, we can use a variant of the enum 'DevtoolsControlMsg'. This enum is used to send messages to the devtools server to update its actors/state according to changes in the browser. We now add HTTPRequest and HHTPResponse variant to the DevtoolsControlMsg enum. We can now use the HTTP loaders' load function to send the HTTPRequest and HHTPResponse to the main loop in the run_server, where it can be received using a receiver. This is done by adding an argument, Sender<DevtoolsControlMsg> to the load function.

	~~[[File:uml_enum.jpg]]~~

	=='''Design Patterns'''==		=='''Design Patterns'''==