Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:21:44Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]
[[File:Use_Case_-_Storage.png‎|right]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's). 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance is same for that URL. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:20:32Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|upright|left]]
[[File:Use_Case_-_Storage.png‎|upright]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object. 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance for that URL must be the same. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:20:20Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|upright|left]]
[[File:Use_Case_-_Storage.png‎|thumb]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object. 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance for that URL must be the same. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

File:Use Case - Storage.png

2014-11-18T03:18:44Z

Vankam:

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:16:52Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|upright|left]]
[[File:Use_Case_Storage.jpg|thumb]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object. 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance for that URL must be the same. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:15:44Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|upright|left]]
[[File:Use_Case_Storage.jpg|upright|thumb]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object. 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance for that URL must be the same. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:15:28Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|upright|left]]
[[File:Use_Case_Storage.jpg|thumb]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object. 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance for that URL must be the same. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:12:16Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|thumb|left]]
[[File:Use_Case_Storage.jpg|thumb]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object. 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance for that URL must be the same. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:11:06Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|thumb|left]]
[[File:Use_Case_Storage.jpg|thumb|right]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object. 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance for that URL must be the same. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:08:05Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|200px|left]]
[[File:Use_Case_Storage.jpg|right]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object. 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance for that URL must be the same. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:07:48Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]
[[File:Use_Case_Storage.jpg|200px|right]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object. 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance for that URL must be the same. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:07:11Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]
[[File:Use_Case_Storage.jpg|right]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object. 
2. Thereby the user will be creating multiple storage instances. 
3. An user can traverse deep into the website but the storage instance for that URL must be the same. 
4. The user can reopen the domain for a later period. 

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:06:51Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]
[[File:Use_Case_Storage.jpg|right]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

1. Here the user can open multiple domains( multiple URL's)where each domain will have a separate Storage object.
2. Thereby the user will be creating multiple storage instances.
3. An user can traverse deep into the website but the storage instance for that URL must be the same.
4. The user can reopen the domain for a later period.

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:02:49Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]
[[File:Use_Case_Storage.jpg|right]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

'''Use Case Functionality'''

Here the user can

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:02:08Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]
[[File:Use_Case_Storage.jpg|right]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

Here the user can

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:01:44Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

[[File:Use_Case_Storage.jpg|right]]

Here the user can

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:01:18Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]

'''Steps:'''

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

[[File:Use_Case_Storage.jpg|right]]

Here the user can

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T03:00:22Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]

Steps:

1. First, we need to build rust and servo. 
2. Generate the corresponding WebIDL bindings - Storage.webidl 
3. Define Storage.rs which has the actual code for creating the storage object. 
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. 
5. Build the servo again. 

[[File:Use_Case_Storage.jpg]]

Here the user can

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:57:47Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]

Steps:

# First, we need to build rust and servo.
# Generate the corresponding WebIDL bindings - Storage.webidl
# Define Storage.rs which has the actual code for creating the storage object.
# Call the receiver via a channel- this is actually used for creating an instance for each unique URL.
## Build the servo again.

[[File:Use_Case_Storage.jpg]]

Here the user can

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:56:50Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]

Steps:

# First, we need to build rust and servo.
# Generate the corresponding WebIDL bindings - Storage.webidl
# Define Storage.rs which has the actual code for creating the storage object.
# Call the receiver via a channel- this is actually used for creating an instance for each unique URL.
# Build the servo again.

[[File:Use_Case_Storage.jpg]]

Here the user can

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:55:22Z

Vankam: `

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png|left]]

Steps:

1. First, we need to build rust and servo.
2. Generate the corresponding WebIDL bindings - Storage.webidl
3. Define Storage.rs which has the actual code for creating the storage object.
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL.
5. Build the servo again.

[[File:Use_Case_Storage.jpg]]

Here the user can

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:47:09Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

'''Flow Chart'''
----

[[File:Flow_Chart_Storage.png|left]]

'''Use Case'''
----

[[File:Use_Case_Storage.jpg]]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:45:06Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

Flow Chart Use Case
[[File:Flow_Chart_Storage.png|left]] [[File:Use_Case_Storage.jpg]]

asdfasd
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:44:33Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

Flow Chart
[[File:Flow_Chart_Storage.png|left]] [[File:Use_Case_Storage.jpg]]

asdfasd
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:44:01Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

Flow Chart
[[File:Flow_Chart_Storage.png|left]] [[File:Use_Case_Storage.jpg|right]]

asdfasd
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:43:30Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

Flow Chart
[[File:Flow_Chart_Storage.png|left]]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?]
Question 3: Does the design incorporate all of the functionality required? (See http://courses.ncsu.edu/csc517/common/homework/project/ideas.html?) [Or, if this is a project idea submitted by students, does the design document clearly explain the required functionality?][[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:42:59Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

Flow Chart
[[File:Flow_Chart_Storage.png|left]]Use Case [[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:42:16Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

Flow Chart
[[File:Flow_Chart_Storage.png|left]]

Use Case
[[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:41:54Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

Flow Chart
[[File:Flow_Chart_Storage.png|left]]

adfasdfasdf
dsfasdf
adsf
asdf
asdf
adsf
asdfa
asdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfa

Use Case
[[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:41:26Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

Flow Chart
[[File:Flow_Chart_Storage.png|left]]

adfasdfasdf
dsfasdf
adsf
asdf
asdf
adsf
asdfa
asdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfaasdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfa

Use Case
[[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:34:14Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

Flow Chart
[[File:Flow_Chart_Storage.png|left]]

adfasdfasdf
dsfasdf
adsf
asdf
asdf
adsf
asdfa

Use Case
[[File:Use_Case_Storage.jpg|right]]
asdfasdfasdfasdfasdf
adsfasdf
adsf
asdf
asdf
adsf
asdfa

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:33:20Z

Vankam: /* UML Diagrams */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

Flow Chart
[[File:Flow_Chart_Storage.png|left]]

Use Case
[[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-18T02:31:55Z

Vankam: /* Requirement Analysis https://github.com/servo/servo/wiki/Storage-student-project */

== Implement Window.sessionStorage ==

This is the design document for the task <code>[http://github.com/servo/servo/wiki/Storage-student-project Implement Window.sessionStorage]</code> for the [http://www.mozilla.org/ Mozilla] research project [http://github.com/servo/servo/wiki/Design Servo].

__TOC__

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

== Background ==

=== [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] ===
The web storage specification defines the means by which a web application can store string key/value pairs in a browser and later retrieve them for use.<ref>https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage</ref> It supports persistent data storage, similar to [http://en.wikipedia.org/wiki/HTTP_cookie cookies] but with a greatly enhanced capacity and no information stored in the [http://en.wikipedia.org/wiki/List_of_HTTP_headers HTTP request header].<ref>http://en.wikipedia.org/wiki/Web_storage</ref> There are two types of web storage: [http://html.spec.whatwg.org/multipage/webstorage.html#dom-localstorage local storage] and [http://html.spec.whatwg.org/multipage/webstorage.html#dom-sessionstorage session storage].

Browsers that support web storage have the global variables 'sessionStorage' and 'localStorage' declared at the [http://developer.mozilla.org/en-US/docs/Web/API/Window?redirectlocale=en-US&redirectslug=DOM%2Fwindow window] level. The following JavaScript code gives an example of how to use web storage:

'''sessionStorage'''
<pre>
// Store value on browser for duration of the session
sessionStorage.setItem('key', 'value');

// Retrieve value (gets deleted when browser is closed and re-opened)
alert(sessionStorage.getItem('key'));
</pre>

'''localStorage'''
<pre>
// Store value on the browser beyond the duration of the session
localStorage.setItem('key', 'value');

// Retrieve value (persists even after closing and re-opening the browser)
alert(localStorage.getItem('key'));
</pre>

== Project Description ==

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the web storage specification in the Servo browser. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

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

In order to introduce the support for session storage and local storage in the Servo Broswer, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a high level overview of the various steps that have been planned for this project:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Architecture <ref>https://github.com/servo/servo/wiki/Design</ref>==

[[File:task.jpg]]

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

== Component Design ==
[[File:servo.jpg]]

There will be a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol. The task is runnning in the background and waits to receive the data sent from the web page.

=== Task <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel <ref>http://doc.rust-lang.org/guide-tasks.html</ref>===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Design Pattern ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the web storage provided by the browser. However, the actual data is stored somewhere else(Servo Memory Space). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML Diagrams ==

[[File:Flow_Chart_Storage.png]][[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

Some of the test cases which will be used to validate our changes are as follows:

* Allow a web page to clear its session storage
* Allow a web page to store an item in its session storage
* Allow a web page to retrieve stored items from its session storage
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain
* Check the number of items stored in session storage
* On removing an item from storage, it should be inaccessible
* Should return null as value for a key not present in the session storage
* Should give an error on exceeding the space limit of session storage

The complete list of test cases can be found [http://github.com/servo/web-platform-tests/tree/servo/webstorage here].

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:14:56Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

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

[[File:Flow_Chart_Storage.png]][[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:14:42Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

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

[[File:Flow_Chart_Storage.png|center]][[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:14:04Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:Flow_Chart_Storage.png]][[File:Use_Case_Storage.jpg|right]]

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:13:30Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

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

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

File:Use Case Storage.jpg

2014-11-11T23:13:03Z

Vankam: uploaded a new version of "File:Use Case Storage.jpg"

File:Use Case Storage.jpg

2014-11-11T23:12:08Z

Vankam:

File:Flow Chart Storage.png

2014-11-11T23:11:18Z

Vankam: uploaded a new version of "File:Flow Chart Storage.png"

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:09:19Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

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

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

File:Flow Chart Storage.png

2014-11-11T23:08:57Z

Vankam: uploaded a new version of "File:Flow Chart Storage.png"

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:07:09Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:Flow_Chart_Storage.png|200px]]

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:06:54Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

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

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

File:Flow Chart Storage.png

2014-11-11T23:06:37Z

Vankam:

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:05:47Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

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

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:05:21Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:Flow_Chart_Storage.jpg|200px]]

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:04:54Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

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

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

CSC/ECE 517 Fall 2014/final design doc M1450 navr

2014-11-11T23:04:40Z

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

== Introduction ==

=== [http://www.rust-lang.org/ Rust]===

Rust is a modern systems programming language focusing on safety and speed to build reliable and efficient systems <ref> http://doc.rust-lang.org/nightly/intro.html </ref>. It accomplishes the goals of memory safe without using garbage collection and it supports concurrency and parallelism in building platforms.

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. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== [http://github.com/servo/servo/wiki/Design Servo] ===

Mozilla Research team is currently working on an experimental project to develop a new Web browser engine "Servo", that is capable of supporting a variety of current and next generation of hardware like mobile devices, multi-core processors and high-performance GPUs. Servo builds on top of Rust to provide a secure and reliable foundation. It is currently developed on 64 bit devices.<ref> https://www.mozilla.org/en-US/research/projects/ </ref>

The main objectives of this experimentation project is improving the layout to graphics rendering - to optimize for power efficiency and maximize parallelism. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

=== Purpose ===

The purpose of this project is to introduce the support related to sessionstorage and localstorage in Servo Broswer, for this we have to create Storage structure and allow web pages to store data in the Servo memory space.

=== Background ===

Persistent storage on the web is used by many services such as the popular Disqus commenting interface. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause.

== Architecture ==

[[File:task.jpg]]

The Architecture comprises of a Storage Task which will be responsible to hold all the data that the web page requests to save. This happens via Channels in Rust, which implements a Sender Receiver protocol, the task is runnning in the background and waits to receive the data sent from the web page.

=== Architecture Explained ===
*Each box represents a Rust task.
*Blue boxes represent the primary tasks in the browser pipeline.
*Gray boxes represent tasks auxiliary to the browser pipeline.
*White boxes represent worker tasks. Each such box represents several tasks, the precise number of which will vary with the workload.
*Dashed lines indicate supervisor relationships.
*Solid lines indicate communication channels.

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

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement the [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage Web Storage] specification in Servo. Implementing this important specification in Servo will allow stateful web applications to run, and will help expose any architectural problems that Servo's radical design may cause. <ref> https://github.com/servo/servo/wiki/Storage-student-project</ref>

Below is a high level overview of the various steps that need to be carried out to achieve this:

* Create the Storage interface and its stub implementation.
* Create the WindowSessionStorage interface making it return a Storage instance.
* Create a Storage Task which will be used to contain all stored data.
* Define a message-passing interface for reading and writing stored data for a particular browser tab.
* Use the Storage task in the implementation of Storage.
* When the value of a stored data is changed, notify its respective browser tab.
* Pass as many tests as possible.
* Implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.

== Data Design ==

=== Data Description ===

''The following are the data structures that will be used.''

'''Storage''' | TreeMap<String,String>

'''UrlMap''' | TreeMap<String,TreeMap<String,String>>

== Component Design ==
[[File:servo.jpg]]
=== Task ===
Rust provides safe concurrent abstractions through a number of core library primitives. This guide will describe the concurrency model in Rust, how it relates to the Rust type system, and introduce the fundamental library abstractions for constructing concurrent programs.

Tasks provide failure isolation and recovery. When a fatal error occurs in Rust code as a result of an explicit call to panic!(), an assertion failure, or another invalid operation, the runtime system destroys the entire task. Unlike in languages such as Java and C++, there is no way to catch an exception. Instead, tasks may monitor each other to see if they panic.

Tasks use Rust's type system to provide strong memory safety guarantees. In particular, the type system guarantees that tasks cannot induce a data race from shared mutable state.

<pre>
// Generate some state locally
let child_task_number = generate_task_number();

spawn(proc() {
// Capture it in the remote task
println!("I am child number {}", child_task_number);
});
</pre>

=== Channel ===
Now that we have spawned a new task, it would be nice if we could communicate with it. For this, we use channels. A channel is simply a pair of endpoints: one for sending messages and another for receiving messages.

The simplest way to create a channel is to use the channel function to create a (Sender, Receiver) pair. In Rust parlance, a sender is a sending endpoint of a channel, and a receiver is the receiving endpoint.
<pre>
let (tx, rx): (Sender<int>, Receiver<int>) = channel();

spawn(proc() {
let result = some_expensive_computation();
tx.send(result);
});

some_other_expensive_computation();
let result = rx.recv();
</pre>

== Design patterns ==

We will be using "Delegation Pattern" in our project. The Storage interface is used by web applications to access the Web Storage provided by the browser. However, the actual data is stored somewhere else(Database/FileSystem/Memory). So, it makes sense to create another class which will maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We will create a class "WebStorageTask" for this purpose.

== UML diagrams (Eg use case diagram, class diagrams) ==
[[File:File.png|200px|thumb|left|alt text]]

== Proposed Test Cases ==

== Further Readings ==

Learning Rust by Examples: http://rustbyexample.com/ 
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ 

== References ==
<references/>

File:Flow Chart Storage.jpg

2014-11-11T23:04:05Z

Vankam: uploaded a new version of "File:Flow Chart Storage.jpg"