Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2015

2015-11-06T17:52:41Z

Nkdalmia:

==Writing Assignment 1==
*[[CSC/ECE 517 Spring 2015/ch1a 17 WL]]
*[[CSC/ECE 517 Spring 2015/ch1a 5 ZX]]
*[[CSC/ECE 517 Spring 2015/ch1a 6 TZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 4 RW]]
*[[CSC/ECE 517 Spring 2015/ch1a 7 SA]]
*[[CSC/ECE 517 Spring 2015/ch1a 9 RA]]
*[[CSC/ECE 517 Spring 2015/ch1a 14 RI]]
*[[CSC/ECE 517 Spring 2015/ch1a 1 DZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 20 HA]]
*[[CSC/ECE 517 Spring 2015/ch1a 3 RF]]
*[[CSC/ECE 517 Spring 2015/ch1a 12 LS]]
*[[CSC/ECE 517 Spring 2015/ch1a 13 MA]]
*[[CSC/ECE 517 Spring 2015/ch1a 2 WA]]
*[[CSC/ECE 517 Spring 2015/ch1b 21 QW]]
*[[CSC/ECE 517 Spring 2015/ch1b 23 MS]]
*[[CSC/ECE 517 Spring 2015/ch1b 10 GL]]
*[[CSC/ECE 517 Spring 2015/ch1b 27 VC]]
*[[CSC/ECE 517 Spring 2015/ch1b 22 SF]]
*[[CSC/ECE 517 Spring 2015/ch1b 15 SH]]
*[[CSC/ECE 517 Spring 2015/ch1b 18 AS]]

==Writing Assignment 2==
*[[CSC/ECE 517 Spring 2015/oss E1502 wwj]]
*[[CSC/ECE 517 Fall 2014/oss E1508 MRS]]
*[[CSC/ECE 517 Spring 2015/oss E1504 IMV]]
*[[CSC/ECE 517 Spring 2015/oss E1505 xzl]]
*[[CSC/ECE 517 Spring 2015/oss E1509 lds]]
*[[CSC/ECE 517 Spring 2015/oss E1510 FLP]]
*[[CSC/ECE 517 Spring 2015/oss E1506 SYZ]]
*[[CSC/ECE 517 Spring 2015/oss S1504 AAC]]
*[[CSC/ECE 517 Spring 2015/oss E1507 DG]]
*[[CSC/ECE 517 Spring 2015/oss M1502 GVJ]]
*[[CSC/ECE 517 Spring 2015/oss M1503 EDT]]
*[[CSC/ECE 517 Spring 2015/oss E1503 RSA]]
*[[CSC/ECE 517 Spring 2015/oss E1501 YWS]]
*[[CSC/ECE 517 Spring 2015/oss S1501 OA]]

==Final Project Design Document==

*[[CSC/ECE 517 Spring 2015 E1526 MPRI]]
*[[CSC/ECE 517 Spring 2015 S1503 LWJZ]]
*[[CSC/ECE 517 Spring 2015 S1524 FSZZ]]
*[[CSC/ECE 517 Spring 2015 M1503 EDTS]]
*[[CSC/ECE 517 Spring 2015 E1529 GLDS]]
*[[CSC/ECE 517 Spring 2015 E1525 TIAA]]
*[[CSC/ECE 517 Spring 2015 E1522 Visualization]]
*[[CSC/ECE 517 Spring 2015 E1527 SWAR]]

==Final Project Report==
*[[CSC/ECE 517 Spring 2015 E1526]]

File:Got23.jpg

2015-11-06T17:51:58Z

Nkdalmia:

File:Got21.jpg

2015-11-06T17:50:07Z

Nkdalmia:

CSC/ECE 517 Spring 2015/test page

2015-11-06T17:46:07Z

Nkdalmia:

[[Gottest11.jpg]]

File:Gottest11.jpg

2015-11-06T17:45:05Z

Nkdalmia:

CSC/ECE 517 Spring 2015/test page

2015-11-06T17:41:29Z

Nkdalmia: Created page with "got2.jpg"

[[got2.jpg]]

File:Got 2.jpg

2015-11-06T17:36:19Z

Nkdalmia:

CSC/ECE 517 Spring 2015

2015-11-06T17:28:41Z

Nkdalmia:

*[[CSC/ECE 517 Spring 2015/test page]]
==Writing Assignment 1==
*[[CSC/ECE 517 Spring 2015/ch1a 17 WL]]
*[[CSC/ECE 517 Spring 2015/ch1a 5 ZX]]
*[[CSC/ECE 517 Spring 2015/ch1a 6 TZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 4 RW]]
*[[CSC/ECE 517 Spring 2015/ch1a 7 SA]]
*[[CSC/ECE 517 Spring 2015/ch1a 9 RA]]
*[[CSC/ECE 517 Spring 2015/ch1a 14 RI]]
*[[CSC/ECE 517 Spring 2015/ch1a 1 DZ]]
*[[CSC/ECE 517 Spring 2015/ch1a 20 HA]]
*[[CSC/ECE 517 Spring 2015/ch1a 3 RF]]
*[[CSC/ECE 517 Spring 2015/ch1a 12 LS]]
*[[CSC/ECE 517 Spring 2015/ch1a 13 MA]]
*[[CSC/ECE 517 Spring 2015/ch1a 2 WA]]
*[[CSC/ECE 517 Spring 2015/ch1b 21 QW]]
*[[CSC/ECE 517 Spring 2015/ch1b 23 MS]]
*[[CSC/ECE 517 Spring 2015/ch1b 10 GL]]
*[[CSC/ECE 517 Spring 2015/ch1b 27 VC]]
*[[CSC/ECE 517 Spring 2015/ch1b 22 SF]]
*[[CSC/ECE 517 Spring 2015/ch1b 15 SH]]
*[[CSC/ECE 517 Spring 2015/ch1b 18 AS]]

==Writing Assignment 2==
*[[CSC/ECE 517 Spring 2015/oss E1502 wwj]]
*[[CSC/ECE 517 Fall 2014/oss E1508 MRS]]
*[[CSC/ECE 517 Spring 2015/oss E1504 IMV]]
*[[CSC/ECE 517 Spring 2015/oss E1505 xzl]]
*[[CSC/ECE 517 Spring 2015/oss E1509 lds]]
*[[CSC/ECE 517 Spring 2015/oss E1510 FLP]]
*[[CSC/ECE 517 Spring 2015/oss E1506 SYZ]]
*[[CSC/ECE 517 Spring 2015/oss S1504 AAC]]
*[[CSC/ECE 517 Spring 2015/oss E1507 DG]]
*[[CSC/ECE 517 Spring 2015/oss M1502 GVJ]]
*[[CSC/ECE 517 Spring 2015/oss M1503 EDT]]
*[[CSC/ECE 517 Spring 2015/oss E1503 RSA]]
*[[CSC/ECE 517 Spring 2015/oss E1501 YWS]]
*[[CSC/ECE 517 Spring 2015/oss S1501 OA]]

==Final Project Design Document==

*[[CSC/ECE 517 Spring 2015 E1526 MPRI]]
*[[CSC/ECE 517 Spring 2015 S1503 LWJZ]]
*[[CSC/ECE 517 Spring 2015 S1524 FSZZ]]
*[[CSC/ECE 517 Spring 2015 M1503 EDTS]]
*[[CSC/ECE 517 Spring 2015 E1529 GLDS]]
*[[CSC/ECE 517 Spring 2015 E1525 TIAA]]
*[[CSC/ECE 517 Spring 2015 E1522 Visualization]]
*[[CSC/ECE 517 Spring 2015 E1527 SWAR]]

==Final Project Report==
*[[CSC/ECE 517 Spring 2015 E1526]]

CSC/ECE 517 Fall 2015

2015-09-21T04:00:54Z

Nkdalmia: /* Writing Assignment 2 */

==Writing Assignment 2==
*[[CSC/ECE_517_Fall_2015/sample_page]]

CSC/ECE 517 Fall 2015

2015-09-21T03:59:33Z

Nkdalmia: Created page with "==Writing Assignment 2== *CSC/ECE 517 Fall 2015/oss E1501 nnn"

==Writing Assignment 2==
*[[CSC/ECE 517 Fall 2015/oss E1501 nnn]]

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

2014-12-04T05:00:54Z

Nkdalmia: /* Design Pattern */

== 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 Browser, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a overview of the various steps identified as part of requirement analysis:

'''Storage Interface'''
* We have to create the Storage interface and its stub implementation.
* This interface is used by the web pages to communicate to the web storage.

'''WindowSessionStorage Interface'''
* We have to create the WindowSessionStorage interface which will return a Storage instance.
* A web page will use this interface to access its session storage.

'''WebStorageTask'''
* We have to create a Storage Task which will be used to store all the web storage data.
* This is a separate thread which starts when browser starts.
* The class implementing the Storage interface uses it to store and retrieve the actual data.

'''Communication Channel'''
* It provides the means to communicate to the separate thread 'WebStorageTask'.
* We need to define a message-passing interface for reading and writing stored data for a particular browser tab and use it in the implementation of Storage interface to communicate to WebStorageTask.

'''Notification Event'''
* We need to notify the respective browser tab when the value of a stored data is changed so that other browser objects which may be using this data can take appropriate action.

'''Web Storage Tests'''
* We need to pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* These tests are part of the web storage specification. Any browser implementing the web storage interface must pass as many tests as possible out of these.

'''WindowLocalStorage Interface'''
* We need to implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.
* This will provide the interface to access browser's local storage.

== Implementation ==

The implementation of the project was divided into the following milestones :

* '''Create and stub the Storage WebIDL interface defined in the spec :''' This milestone involved the initial creation of the Storage interface on which the entire project is based. The storage web idl was created as defined in the specifications : https://html.spec.whatwg.org/multipage/webstorage.html#storage-2

* '''Create and stub the WindowSessionStorage WebIDL interface defined in the spec, making it return a Storage instance''' : Once the Storage interface was created, we had to implement the interface to actually define the functions which were a part of the interface. Here we extended the Storage interface to specialize it as Session Storage interface namely WindowSessionStorage. The methods in this interface were then further implemented in Storage.rs which was made to return a Storage instance to the web page or application requiring the support of sessionstorage.

* '''Create a storage task (similar to the resource task) which will contain all stored data''' : The actual data is stored in a background task known as Storage Task, A task in rust terms is nothing but a thread which can run in the background keep polling until it is required, it does so by looping over a channel until a request comes its way. The Storage task contains a HashMap of TreeMap. The Hashmap is used to store the storage data for all the sites. Its keys represent the origin of the request (determined from the URL it is coming from). There is an entry in the HashMap for each different origin. The respective value represents the storage data for the site. This site specific data is stored as a TreeMap which maintains the <key , value> pair in a ordered fashion. Thus the storage task contains the actual data structure which holds all the values and the Storage.rs acts as a mediator between the object and the data stored in the task.

* '''Define a message-passing interface for reading and writing stored data for a particular origin''': The Storage object requires a medium to delegate the functions to storage task where the actual implementation takes place. This is done using [http://doc.rust-lang.org/std/comm/fn.channel.html Channels]. There are 2 major channels. First one is the one which the storage task creates and keeps on listening for any the request. The other is when the storage object wants to get some data from the task. The Storage object creates a temporary channel on which it listens for any reply by the Storage task. This is how the message-passing interface has been implemented in the given milestone.

* '''Store a channel to the storage task in the Page structure that sends messages from the previous interface, and make use of it in the implementation of Storage''': The storage object requires to know the channel on which the task is looping in order to send it requests for get, set or other functions. This is done by storing the channel that the storage task creates in the Page Structure which acts as a common object between these 2. Hence, by passing the created channel to the page structure it can now be accessed and utilized by the Storage object in order to delegate the methods onto the storage task and communicate.

== 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 data structure has been used ''

'''StorageTask''' | HashMap<String, TreeMap<DomString,DomString>>

== Design Pattern ==

We have used the '''"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 should maintain the actual stored data. The Storage class can then delegate the task of storing/retrieving data to this class. We have created a class "StorageTask" for this purpose.

Also we are using an '''"Observer Pattern"''' where the Storage task runs in the background and observes the commands issued using a channel. It keeps on listening to changes on a port and as soon as it receives a message i.e. sees a call towards it, it performs the required function.

== UML Diagrams ==

=== Flow Chart ===
[[File:Flow_Chart_Storage.png]]

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 Diagram ===
[[File:Use_Case_-_Storage.png‎]]

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 ''i.e. storage.clear() function should work''
* Allow a web page to store an item in its session storage ''i.e. test storage.setitem(key,value)''
* Allow a web page to retrieve stored items from its session storage ''i.e. test storage.getitem(key)''
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain ''i.e. try to access elements by forging url
* Check the number of items stored in session storage i.e storage.count()''
* On removing an item from storage, it should be inaccessible ''i.e check if storage.remove(key) is functional''
* Should return null as value for a key not present in the session storage ''i.e. test storage.getitem(key) for non-existent key''
* Should give an error on exceeding the space limit of session storage ''i.e check for available memory on each command''

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-12-04T04:58:38Z

Nkdalmia: /* Data Description */

== 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 Browser, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a overview of the various steps identified as part of requirement analysis:

'''Storage Interface'''
* We have to create the Storage interface and its stub implementation.
* This interface is used by the web pages to communicate to the web storage.

'''WindowSessionStorage Interface'''
* We have to create the WindowSessionStorage interface which will return a Storage instance.
* A web page will use this interface to access its session storage.

'''WebStorageTask'''
* We have to create a Storage Task which will be used to store all the web storage data.
* This is a separate thread which starts when browser starts.
* The class implementing the Storage interface uses it to store and retrieve the actual data.

'''Communication Channel'''
* It provides the means to communicate to the separate thread 'WebStorageTask'.
* We need to define a message-passing interface for reading and writing stored data for a particular browser tab and use it in the implementation of Storage interface to communicate to WebStorageTask.

'''Notification Event'''
* We need to notify the respective browser tab when the value of a stored data is changed so that other browser objects which may be using this data can take appropriate action.

'''Web Storage Tests'''
* We need to pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* These tests are part of the web storage specification. Any browser implementing the web storage interface must pass as many tests as possible out of these.

'''WindowLocalStorage Interface'''
* We need to implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.
* This will provide the interface to access browser's local storage.

== Implementation ==

The implementation of the project was divided into the following milestones :

* '''Create and stub the Storage WebIDL interface defined in the spec :''' This milestone involved the initial creation of the Storage interface on which the entire project is based. The storage web idl was created as defined in the specifications : https://html.spec.whatwg.org/multipage/webstorage.html#storage-2

* '''Create and stub the WindowSessionStorage WebIDL interface defined in the spec, making it return a Storage instance''' : Once the Storage interface was created, we had to implement the interface to actually define the functions which were a part of the interface. Here we extended the Storage interface to specialize it as Session Storage interface namely WindowSessionStorage. The methods in this interface were then further implemented in Storage.rs which was made to return a Storage instance to the web page or application requiring the support of sessionstorage.

* '''Create a storage task (similar to the resource task) which will contain all stored data''' : The actual data is stored in a background task known as Storage Task, A task in rust terms is nothing but a thread which can run in the background keep polling until it is required, it does so by looping over a channel until a request comes its way. The Storage task contains a HashMap of TreeMap. The Hashmap is used to store the storage data for all the sites. Its keys represent the origin of the request (determined from the URL it is coming from). There is an entry in the HashMap for each different origin. The respective value represents the storage data for the site. This site specific data is stored as a TreeMap which maintains the <key , value> pair in a ordered fashion. Thus the storage task contains the actual data structure which holds all the values and the Storage.rs acts as a mediator between the object and the data stored in the task.

* '''Define a message-passing interface for reading and writing stored data for a particular origin''': The Storage object requires a medium to delegate the functions to storage task where the actual implementation takes place. This is done using [http://doc.rust-lang.org/std/comm/fn.channel.html Channels]. There are 2 major channels. First one is the one which the storage task creates and keeps on listening for any the request. The other is when the storage object wants to get some data from the task. The Storage object creates a temporary channel on which it listens for any reply by the Storage task. This is how the message-passing interface has been implemented in the given milestone.

* '''Store a channel to the storage task in the Page structure that sends messages from the previous interface, and make use of it in the implementation of Storage''': The storage object requires to know the channel on which the task is looping in order to send it requests for get, set or other functions. This is done by storing the channel that the storage task creates in the Page Structure which acts as a common object between these 2. Hence, by passing the created channel to the page structure it can now be accessed and utilized by the Storage object in order to delegate the methods onto the storage task and communicate.

== 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 data structure has been used ''

'''StorageTask''' | HashMap<String, TreeMap<DomString,DomString>>

== 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.

Also we are using an '''"Observer Pattern"''' where the Storage task will run in the background and observe the commands issued using a channel, it will keep listening to changes on a port and as soon as it receives a message i.e. sees a call towards it , it will perform the required function.

== UML Diagrams ==

=== Flow Chart ===
[[File:Flow_Chart_Storage.png]]

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 Diagram ===
[[File:Use_Case_-_Storage.png‎]]

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 ''i.e. storage.clear() function should work''
* Allow a web page to store an item in its session storage ''i.e. test storage.setitem(key,value)''
* Allow a web page to retrieve stored items from its session storage ''i.e. test storage.getitem(key)''
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain ''i.e. try to access elements by forging url
* Check the number of items stored in session storage i.e storage.count()''
* On removing an item from storage, it should be inaccessible ''i.e check if storage.remove(key) is functional''
* Should return null as value for a key not present in the session storage ''i.e. test storage.getitem(key) for non-existent key''
* Should give an error on exceeding the space limit of session storage ''i.e check for available memory on each command''

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-12-04T04:57:11Z

Nkdalmia: /* Implementation */

== 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 Browser, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a overview of the various steps identified as part of requirement analysis:

'''Storage Interface'''
* We have to create the Storage interface and its stub implementation.
* This interface is used by the web pages to communicate to the web storage.

'''WindowSessionStorage Interface'''
* We have to create the WindowSessionStorage interface which will return a Storage instance.
* A web page will use this interface to access its session storage.

'''WebStorageTask'''
* We have to create a Storage Task which will be used to store all the web storage data.
* This is a separate thread which starts when browser starts.
* The class implementing the Storage interface uses it to store and retrieve the actual data.

'''Communication Channel'''
* It provides the means to communicate to the separate thread 'WebStorageTask'.
* We need to define a message-passing interface for reading and writing stored data for a particular browser tab and use it in the implementation of Storage interface to communicate to WebStorageTask.

'''Notification Event'''
* We need to notify the respective browser tab when the value of a stored data is changed so that other browser objects which may be using this data can take appropriate action.

'''Web Storage Tests'''
* We need to pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* These tests are part of the web storage specification. Any browser implementing the web storage interface must pass as many tests as possible out of these.

'''WindowLocalStorage Interface'''
* We need to implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.
* This will provide the interface to access browser's local storage.

== Implementation ==

The implementation of the project was divided into the following milestones :

* '''Create and stub the Storage WebIDL interface defined in the spec :''' This milestone involved the initial creation of the Storage interface on which the entire project is based. The storage web idl was created as defined in the specifications : https://html.spec.whatwg.org/multipage/webstorage.html#storage-2

* '''Create and stub the WindowSessionStorage WebIDL interface defined in the spec, making it return a Storage instance''' : Once the Storage interface was created, we had to implement the interface to actually define the functions which were a part of the interface. Here we extended the Storage interface to specialize it as Session Storage interface namely WindowSessionStorage. The methods in this interface were then further implemented in Storage.rs which was made to return a Storage instance to the web page or application requiring the support of sessionstorage.

* '''Create a storage task (similar to the resource task) which will contain all stored data''' : The actual data is stored in a background task known as Storage Task, A task in rust terms is nothing but a thread which can run in the background keep polling until it is required, it does so by looping over a channel until a request comes its way. The Storage task contains a HashMap of TreeMap. The Hashmap is used to store the storage data for all the sites. Its keys represent the origin of the request (determined from the URL it is coming from). There is an entry in the HashMap for each different origin. The respective value represents the storage data for the site. This site specific data is stored as a TreeMap which maintains the <key , value> pair in a ordered fashion. Thus the storage task contains the actual data structure which holds all the values and the Storage.rs acts as a mediator between the object and the data stored in the task.

* '''Define a message-passing interface for reading and writing stored data for a particular origin''': The Storage object requires a medium to delegate the functions to storage task where the actual implementation takes place. This is done using [http://doc.rust-lang.org/std/comm/fn.channel.html Channels]. There are 2 major channels. First one is the one which the storage task creates and keeps on listening for any the request. The other is when the storage object wants to get some data from the task. The Storage object creates a temporary channel on which it listens for any reply by the Storage task. This is how the message-passing interface has been implemented in the given milestone.

* '''Store a channel to the storage task in the Page structure that sends messages from the previous interface, and make use of it in the implementation of Storage''': The storage object requires to know the channel on which the task is looping in order to send it requests for get, set or other functions. This is done by storing the channel that the storage task creates in the Page Structure which acts as a common object between these 2. Hence, by passing the created channel to the page structure it can now be accessed and utilized by the Storage object in order to delegate the methods onto the storage task and communicate.

== 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.

Also we are using an '''"Observer Pattern"''' where the Storage task will run in the background and observe the commands issued using a channel, it will keep listening to changes on a port and as soon as it receives a message i.e. sees a call towards it , it will perform the required function.

== UML Diagrams ==

=== Flow Chart ===
[[File:Flow_Chart_Storage.png]]

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 Diagram ===
[[File:Use_Case_-_Storage.png‎]]

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 ''i.e. storage.clear() function should work''
* Allow a web page to store an item in its session storage ''i.e. test storage.setitem(key,value)''
* Allow a web page to retrieve stored items from its session storage ''i.e. test storage.getitem(key)''
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain ''i.e. try to access elements by forging url
* Check the number of items stored in session storage i.e storage.count()''
* On removing an item from storage, it should be inaccessible ''i.e check if storage.remove(key) is functional''
* Should return null as value for a key not present in the session storage ''i.e. test storage.getitem(key) for non-existent key''
* Should give an error on exceeding the space limit of session storage ''i.e check for available memory on each command''

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-18T04:55:39Z

Nkdalmia: /* 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 Browser, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a overview of the various steps identified as part of requirement analysis:

'''Storage Interface'''
* We have to create the Storage interface and its stub implementation.
* This interface is used by the web pages to communicate to the web storage.

'''WindowSessionStorage Interface'''
* We have to create the WindowSessionStorage interface which will return a Storage instance.
* A web page will use this interface to access its session storage.

'''WebStorageTask'''
* We have to create a Storage Task which will be used to store all the web storage data.
* This is a separate thread which starts when browser starts.
* The class implementing the Storage interface uses it to store and retrieve the actual data.

'''Communication Channel'''
* It provides the means to communicate to the separate thread 'WebStorageTask'.
* We need to define a message-passing interface for reading and writing stored data for a particular browser tab and use it in the implementation of Storage interface to communicate to WebStorageTask.

'''Notification Event'''
* We need to notify the respective browser tab when the value of a stored data is changed so that other browser objects which may be using this data can take appropriate action.

'''Web Storage Tests'''
* We need to pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* These tests are part of the web storage specification. Any browser implementing the web storage interface must pass as many tests as possible out of these.

'''WindowLocalStorage Interface'''
* We need to implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.
* This will provide the interface to access browser's local storage.

== 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.

Also we are using an '''"Observer Pattern"''' where the Storage task will run in the background and observe the commands issued using a channel, it will keep listening to changes on a port and as soon as it receives a message i.e. sees a call towards it , it will perform the required function.

== UML Diagrams ==

=== Flow Chart ===
[[File:Flow_Chart_Storage.png]]

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 Diagram ===
[[File:Use_Case_-_Storage.png‎]]

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 ''i.e. storage.clear() function should work''
* Allow a web page to store an item in its session storage ''i.e. test storage.setitem(key,value)''
* Allow a web page to retrieve stored items from its session storage ''i.e. test storage.getitem(key)''
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain ''i.e. try to access elements by forging url
* Check the number of items stored in session storage i.e storage.count()''
* On removing an item from storage, it should be inaccessible ''i.e check if storage.remove(key) is functional''
* Should return null as value for a key not present in the session storage ''i.e. test storage.getitem(key) for non-existent key''
* Should give an error on exceeding the space limit of session storage ''i.e check for available memory on each command''

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-18T04:48:14Z

Nkdalmia: /* 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 Browser, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a overview of the various steps identified as part of requirement analysis:

'''Storage Interface'''
* We have to create the Storage interface and its stub implementation.
* This interface is used by the web pages to communicate to the web storage.

'''WindowSessionStorage Interface'''
* We have to create the WindowSessionStorage interface which will return a Storage instance.
* A web page will use this interface to access its session storage.

'''WebStorageTask'''
* We have to create a Storage Task which will be used to store all the web storage data.
* This is a separate thread which starts when browser starts.
* The class implementing the Storage interface uses it to store and retrieve the actual data.

'''Communication Channel'''
* It provides the means to communicate to the separate thread 'WebStorageTask'.
* We need to define a message-passing interface for reading and writing stored data for a particular browser tab and use it in the implementation of Storage interface to communicate to WebStorageTask.

'''Notification Event'''
* We need to notify the respective browser tab when the value of a stored data is changed so that other browser objects which may be using this data can take appropriate action.

'''Web Storage Tests'''
* We need to pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* These tests are part of the web storage specification. Any browser implementing the web storage interface must pass as many tests as possible out of these.

'''WindowLocalStorage Interface'''
* We need to implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.
* This will provide the interface to access browser's local storage.

== 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.

Also we are using an '''"Observer Pattern"''' where the Storage task will run in the background and observe the commands issued using a channel, it will keep listening to changes on a port and as soon as it receives a message i.e. sees a call towards it , it will perform the required function.

== 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 ''i.e. storage.clear() function should work''
* Allow a web page to store an item in its session storage ''i.e. test storage.setitem(key,value)''
* Allow a web page to retrieve stored items from its session storage ''i.e. test storage.getitem(key)''
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain ''i.e. try to access elements by forging url
* Check the number of items stored in session storage i.e storage.count()''
* On removing an item from storage, it should be inaccessible ''i.e check if storage.remove(key) is functional''
* Should return null as value for a key not present in the session storage ''i.e. test storage.getitem(key) for non-existent key''
* Should give an error on exceeding the space limit of session storage ''i.e check for available memory on each command''

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-18T04:46:27Z

Nkdalmia: /* 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 Browser, we have to create the Storage structure and allow web pages to store data in the Servo memory space.

Below is a overview of the various steps identified as part of requirement analysis:

'''Storage Interface'''
* We have to create the Storage interface and its stub implementation.
* This interface is used by the web pages to communicate to the web storage.

'''WindowSessionStorage Interface'''
* We have to create the WindowSessionStorage interface which will return a Storage instance.
* A web page will use this interface to access its session storage.

'''WebStorageTask'''
* We have to create a Storage Task which will be used to store all the web storage data.
* This is a separate thread which starts when browser starts.
* The class implementing the Storage interface uses it to store and retrieve the actual data.

'''Communication Channel'''
* It provides the means to communicate to the separate thread 'WebStorageTask'.
* We need to define a message-passing interface for reading and writing stored data for a particular browser tab and use it in the implementation of Storage interface to communicate to WebStorageTask.

'''Notification Event'''
* We need to notify the respective browser tab when the value of a stored data is changed so that other browser objects which may be using this data can take appropriate action.

'''Web Storage Tests'''
* We need to pass as many [http://github.com/servo/web-platform-tests/tree/servo/webstorage tests] as possible.
* These tests are part of the web storage specification. Any browser implementing the web storage interface must pass as many tests as possible out of these.

'''WindowLocalStorage Interface'''
* We need to implement the WindowLocalStorage interface which behaves slightly different from the WindowSessionStorage interface.
* This will provide the interface to access browser's local storage.

== 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.

Also we are using an '''"Observer Pattern"''' where the Storage task will run in the background and observe the commands issued using a channel, it will keep listening to changes on a port and as soon as it receives a message i.e. sees a call towards it , it will perform the required function.

== 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 ''i.e. storage.clear() function should work''
* Allow a web page to store an item in its session storage ''i.e. test storage.setitem(key,value)''
* Allow a web page to retrieve stored items from its session storage ''i.e. test storage.getitem(key)''
* Do not allow a web page to retrieve stored items from the session storage of a web page in another domain ''i.e. try to access elements by forging url
* Check the number of items stored in session storage i.e storage.count()''
* On removing an item from storage, it should be inaccessible ''i.e check if storage.remove(key) is functional''
* Should return null as value for a key not present in the session storage ''i.e. test storage.getitem(key) for non-existent key''
* Should give an error on exceeding the space limit of session storage ''i.e check for available memory on each command''

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-12T05:17:02Z

Nkdalmia: /* Design Patterns */

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

2014-11-12T05:08:13Z

Nkdalmia: /* Proposed Test Cases */

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

2014-11-12T05:04:47Z

Nkdalmia: /* Architecture https://github.com/servo/servo/wiki/Design */

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

2014-11-12T05:04:12Z

Nkdalmia: /* Architecture */

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

2014-11-12T05:02:26Z

Nkdalmia: /* Channel */

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

2014-11-12T05:02:04Z

Nkdalmia: /* Task */

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

2014-11-12T04:59:10Z

Nkdalmia: /* Proposed Test Cases */

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

2014-11-12T04:58:37Z

Nkdalmia: /* Proposed Test Cases */

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

2014-11-12T04:57:45Z

Nkdalmia: /* Proposed Test Cases */

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

2014-11-12T04:49:30Z

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

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

2014-11-12T04:48:59Z

Nkdalmia: /* Design patterns */

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

2014-11-12T04:48:31Z

Nkdalmia: /* Design patterns */

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

2014-11-12T04:44:27Z

Nkdalmia:

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

2014-11-12T04:36:15Z

Nkdalmia: /* Requirement Analysis https://github.com/servo/servo/wiki/Storage-student-project */

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

2014-11-12T04:35:20Z

Nkdalmia: /* Requirement Analysis https://github.com/servo/servo/wiki/Storage-student-project */

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

2014-11-12T04:34:25Z

Nkdalmia: /* Project Description */

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

2014-11-12T04:33:27Z

Nkdalmia: /* Web Storage */

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

2014-11-12T04:32:43Z

Nkdalmia: /* Background */

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

2014-11-12T04:31:06Z

Nkdalmia:

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

2014-11-12T04:29:03Z

Nkdalmia:

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

2014-11-12T04:08:44Z

Nkdalmia:

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

2014-11-11T22:23:32Z

Nkdalmia: /* Design patterns */

== 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) ==

== 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-11T21:28:09Z

Nkdalmia: /* Proposed Test Cases */

== 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 ==

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

== 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 M1451 hsss

2014-11-11T21:26:40Z

Nkdalmia: Undo revision 91737 by Nkdalmia (talk)

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

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

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

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

=== Task Supervision Diagram ===

[[File:TaskSupervision.png]]

=== Task Communication Diagram ===

[[File:TaskCommunication.png]]

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

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

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

2. Then we had to build the rust compiler.
 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Data and component design ==

== Design patterns ==

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

== Proposed Test Cases ==

== References ==
<references/>

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

2014-11-11T21:26:04Z

Nkdalmia:

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

2014-11-11T21:23:49Z

Nkdalmia: /* Requirement analysis https://github.com/servo/servo/wiki/Storage-student-project */

== 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 ==

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

== Proposed Test Cases ==

== References ==
<references/>

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

2014-11-11T16:46:31Z

Nkdalmia: Created page with "== Introduction and architecture of system == == Requirement analysis <ref>https://github.com/servo/servo/wiki/Storage-student-project</ref> == == Data and component design == ..."

== Introduction and architecture of system ==

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

== Data and component design ==

== Design patterns ==

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

== Proposed Test Cases ==

== References ==
<references/>

CSC/ECE 517 Fall 2014

2014-11-11T16:41:39Z

Nkdalmia:

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

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

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

CSC/ECE 517 Fall 2014/OSS M1450 vda

2014-11-06T05:10:57Z

Nkdalmia: /* Design Pattern Used */

== Implement Window.sessionStorage ==

This wiki page contains details on the work done for the initial step of 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>

== Developer Environment Setup <ref>https://github.com/servo/servo/blob/master/README.md</ref>==

=== Installing Required Packages for Servo ===

On OS X (homebrew):
<pre>
brew install automake pkg-config python glfw3 cmake
pip install virtualenv
</pre>

On OS X (MacPorts):
<pre>
sudo port install python27 py27-virtualenv cmake
</pre>

On Debian-based Linuxes:
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

On Fedora:
<pre>
sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd
</pre>

On Arch Linux:
<pre>
sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake
</pre>

=== Building Servo ===

Clone the Servo repository hosted at https://github.com/servo/servo and switch to the working directory.
<pre>
git clone https://github.com/servo/servo
cd servo
</pre>

'''Normal Build'''
<pre>
./mach build
</pre>

'''Building for Android target'''
<pre>
ANDROID_TOOLCHAIN=/path/to/toolchain ANDROID_NDK=/path/to/ndk PATH=$PATH:/path/to/toolchain/bin ./mach build --android
cd ports/android
ANDROID_SDK=/path/to/sdk make install
</pre>

Note: Building Servo will take a considerable amount of time. 

=== Launch Servo ===

Once the build is successful, launch Servo using this command.
<pre>
./mach run tests/html/about-mozilla.html
</pre>

[[File:servo.png]]

== Project Description ==

The [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage 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>

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement this 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>

== Implementation ==

For the OSS project, we had to complete the initial step of the project i.e. create the Storage interface and its stub implementation.

We made the following changes:

* Created a new file called [http://github.com/nkdalmia/servo/tree/master/components/script/dom/webidls Storage.webidl] under the folder '''''components/script/dom/webidls.'''''

* Added the method definitions in the above interface file.

* Created another file called [http://github.com/nkdalmia/servo/tree/master/components/script/dom storage.rs] under the specified folder '''''components/script/dom.'''''

* Added constructor for Storage object and stub implementations of the methods defined in the above mentioned interface file.

* Added our module entry in the file ''''' components/script/lib.rs ''''' so that our files are compiled as part of the Servo build.

* Built the Servo once again and verified that the Servo browser was launching correctly.

== Design Pattern ==

We will be using "Delegation Pattern" for our final project implementation. Our implementation will store the Web Storage data in memory. But, this will change in future once “Servo” has the mechanism to persist data on the client side (for example: in filesystem or database). So, we need to use a design pattern which will help in incorporating this future change without making a lot of changes to our actual implementation.

We can ensure this using "Delegation Pattern".

[[File:Delegation.jpg]]

* We will define a new class 'MemoryStorage' (file memory_storage.rs) which implements the interface 'Storage' (file Storage.webidl).
* The class 'Storage' (file storage.rs) will have a private attribute 'realStorage'
** Object referred by 'realStorage' also implements the interface 'Storage'
** When a new object for 'Storage' class is created, a new 'MemoryStorage' object will be created and assigned to the attribute 'realStorage'
* The APIs in 'Storage' class will delegate the calls to the respective APIs in the object referenced by the 'realStorage' attribute
* Once the mechanism to persist data on client side is available, we can create a new class 'FileStorage' (or 'DBStorage') and assign its object to 'realStorage' during initialization of 'Storage' class. Rest of the code in 'Storage' class will remain unchanged.

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

* 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.

== Further Readings ==

Design and Architecture of Servo: http://github.com/servo/servo/wiki/Design/ 
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:Delegation.jpg

2014-11-06T04:05:49Z

Nkdalmia: uploaded a new version of "File:Delegation.jpg"

CSC/ECE 517 Fall 2014/OSS M1450 vda

2014-10-30T04:14:18Z

Nkdalmia: /* Project Description */

== Implement Window.sessionStorage ==

This wiki page contains details on the work done for the initial step of 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>

== Developer Environment Setup <ref>https://github.com/servo/servo/blob/master/README.md</ref>==

=== Installing Required Packages for Servo ===

On OS X (homebrew):
<pre>
brew install automake pkg-config python glfw3 cmake
pip install virtualenv
</pre>

On OS X (MacPorts):
<pre>
sudo port install python27 py27-virtualenv cmake
</pre>

On Debian-based Linuxes:
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

On Fedora:
<pre>
sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd
</pre>

On Arch Linux:
<pre>
sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake
</pre>

=== Building Servo ===

Clone the Servo repository hosted at https://github.com/servo/servo and switch to the working directory.
<pre>
git clone https://github.com/servo/servo
cd servo
</pre>

'''Normal Build'''
<pre>
./mach build
</pre>

'''Building for Android target'''
<pre>
ANDROID_TOOLCHAIN=/path/to/toolchain ANDROID_NDK=/path/to/ndk PATH=$PATH:/path/to/toolchain/bin ./mach build --android
cd ports/android
ANDROID_SDK=/path/to/sdk make install
</pre>

Note: Building Servo will take a considerable amount of time. 

=== Launch Servo ===

Once the build is successful, launch Servo using this command.
<pre>
./mach run tests/html/about-mozilla.html
</pre>

[[File:servo.png]]

== Project Description ==

The [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage 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>

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement this 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>

== Implementation ==

For the OSS project, we had to complete the initial step of the project i.e. create the Storage interface and its stub implementation.

We made the following changes:

* Created a new file called [http://github.com/nkdalmia/servo/tree/master/components/script/dom/webidls Storage.webidl] under the folder '''''components/script/dom/webidls.'''''

* Added the method definitions in the above interface file.

* Created another file called [http://github.com/nkdalmia/servo/tree/master/components/script/dom storage.rs] under the specified folder '''''components/script/dom.'''''

* Added constructor for Storage object and stub implementations of the methods defined in the above mentioned interface file.

* Added our module entry in the file ''''' components/script/lib.rs ''''' so that our files are compiled as part of the Servo build.

* Built the Servo once again and verified that the Servo browser was launching correctly.

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

* 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.

== Further Readings ==

Design and Architecture of Servo: http://github.com/servo/servo/wiki/Design/ 
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/OSS M1450 vda

2014-10-30T04:06:59Z

Nkdalmia: /* Project Description */

== Implement Window.sessionStorage ==

This wiki page contains details on the work done for the initial step of 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>

== Developer Environment Setup <ref>https://github.com/servo/servo/blob/master/README.md</ref>==

=== Installing Required Packages for Servo ===

On OS X (homebrew):
<pre>
brew install automake pkg-config python glfw3 cmake
pip install virtualenv
</pre>

On OS X (MacPorts):
<pre>
sudo port install python27 py27-virtualenv cmake
</pre>

On Debian-based Linuxes:
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

On Fedora:
<pre>
sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd
</pre>

On Arch Linux:
<pre>
sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake
</pre>

=== Building Servo ===

Clone the Servo repository hosted at https://github.com/servo/servo and switch to the working directory.
<pre>
git clone https://github.com/servo/servo
cd servo
</pre>

'''Normal Build'''
<pre>
./mach build
</pre>

'''Building for Android target'''
<pre>
ANDROID_TOOLCHAIN=/path/to/toolchain ANDROID_NDK=/path/to/ndk PATH=$PATH:/path/to/toolchain/bin ./mach build --android
cd ports/android
ANDROID_SDK=/path/to/sdk make install
</pre>

Note: Building Servo will take a considerable amount of time. 

=== Launch Servo ===

Once the build is successful, launch Servo using this command.
<pre>
./mach run tests/html/about-mozilla.html
</pre>

[[File:servo.png]]

== Project Description ==

The [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage 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 cookies but with a greatly enhanced capacity and no information stored in the 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 window level. The following JavaScript code can be used on browsers to trigger web storage behaviour:

'''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>

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement this 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>

== Implementation ==

For the OSS project, we had to complete the initial step of the project i.e. create the Storage interface and its stub implementation.

We made the following changes:

* Created a new file called [http://github.com/nkdalmia/servo/tree/master/components/script/dom/webidls Storage.webidl] under the folder '''''components/script/dom/webidls.'''''

* Added the method definitions in the above interface file.

* Created another file called [http://github.com/nkdalmia/servo/tree/master/components/script/dom storage.rs] under the specified folder '''''components/script/dom.'''''

* Added constructor for Storage object and stub implementations of the methods defined in the above mentioned interface file.

* Added our module entry in the file ''''' components/script/lib.rs ''''' so that our files are compiled as part of the Servo build.

* Built the Servo once again and verified that the Servo browser was launching correctly.

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

* 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.

== Further Readings ==

Design and Architecture of Servo: http://github.com/servo/servo/wiki/Design/ 
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/OSS M1450 vda

2014-10-30T04:05:15Z

Nkdalmia: /* Project Description */

== Implement Window.sessionStorage ==

This wiki page contains details on the work done for the initial step of 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>

== Developer Environment Setup <ref>https://github.com/servo/servo/blob/master/README.md</ref>==

=== Installing Required Packages for Servo ===

On OS X (homebrew):
<pre>
brew install automake pkg-config python glfw3 cmake
pip install virtualenv
</pre>

On OS X (MacPorts):
<pre>
sudo port install python27 py27-virtualenv cmake
</pre>

On Debian-based Linuxes:
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

On Fedora:
<pre>
sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd
</pre>

On Arch Linux:
<pre>
sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake
</pre>

=== Building Servo ===

Clone the Servo repository hosted at https://github.com/servo/servo and switch to the working directory.
<pre>
git clone https://github.com/servo/servo
cd servo
</pre>

'''Normal Build'''
<pre>
./mach build
</pre>

'''Building for Android target'''
<pre>
ANDROID_TOOLCHAIN=/path/to/toolchain ANDROID_NDK=/path/to/ndk PATH=$PATH:/path/to/toolchain/bin ./mach build --android
cd ports/android
ANDROID_SDK=/path/to/sdk make install
</pre>

Note: Building Servo will take a considerable amount of time. 

=== Launch Servo ===

Once the build is successful, launch Servo using this command.
<pre>
./mach run tests/html/about-mozilla.html
</pre>

[[File:servo.png]]

== Project Description ==

The [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage 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. It supports persistent data storage, similar to cookies but with a greatly enhanced capacity and no information stored in the 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 window level. The following JavaScript code can be used on browsers to trigger web storage behaviour:

'''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>

As part of our [http://github.com/servo/servo/wiki/Storage-student-project project], we have to implement this 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>

== Implementation ==

For the OSS project, we had to complete the initial step of the project i.e. create the Storage interface and its stub implementation.

We made the following changes:

* Created a new file called [http://github.com/nkdalmia/servo/tree/master/components/script/dom/webidls Storage.webidl] under the folder '''''components/script/dom/webidls.'''''

* Added the method definitions in the above interface file.

* Created another file called [http://github.com/nkdalmia/servo/tree/master/components/script/dom storage.rs] under the specified folder '''''components/script/dom.'''''

* Added constructor for Storage object and stub implementations of the methods defined in the above mentioned interface file.

* Added our module entry in the file ''''' components/script/lib.rs ''''' so that our files are compiled as part of the Servo build.

* Built the Servo once again and verified that the Servo browser was launching correctly.

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

* 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.

== Further Readings ==

Design and Architecture of Servo: http://github.com/servo/servo/wiki/Design/ 
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/OSS M1450 vda

2014-10-30T04:05:00Z

Nkdalmia: /* Project Description */

== Implement Window.sessionStorage ==

This wiki page contains details on the work done for the initial step of 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>

== Developer Environment Setup <ref>https://github.com/servo/servo/blob/master/README.md</ref>==

=== Installing Required Packages for Servo ===

On OS X (homebrew):
<pre>
brew install automake pkg-config python glfw3 cmake
pip install virtualenv
</pre>

On OS X (MacPorts):
<pre>
sudo port install python27 py27-virtualenv cmake
</pre>

On Debian-based Linuxes:
<pre>
sudo apt-get install curl freeglut3-dev \
libfreetype6-dev libgl1-mesa-dri libglib2.0-dev xorg-dev \
msttcorefonts gperf g++ cmake python-virtualenv \
libssl-dev libglfw-dev
</pre>

On Fedora:
<pre>
sudo yum install curl freeglut-devel libtool gcc-c++ libXi-devel \
freetype-devel mesa-libGL-devel glib2-devel libX11-devel libXrandr-devel gperf \
fontconfig-devel cabextract ttmkfdir python python-virtualenv expat-devel \
rpm-build openssl-devel glfw-devel cmake
pushd .
cd /tmp
wget http://corefonts.sourceforge.net/msttcorefonts-2.5-1.spec
rpmbuild -bb msttcorefonts-2.5-1.spec
sudo yum install $HOME/rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm
popd
</pre>

On Arch Linux:
<pre>
sudo pacman -S base-devel git python2 python2-virtualenv mesa glfw ttf-font cmake
</pre>

=== Building Servo ===

Clone the Servo repository hosted at https://github.com/servo/servo and switch to the working directory.
<pre>
git clone https://github.com/servo/servo
cd servo
</pre>

'''Normal Build'''
<pre>
./mach build
</pre>

'''Building for Android target'''
<pre>
ANDROID_TOOLCHAIN=/path/to/toolchain ANDROID_NDK=/path/to/ndk PATH=$PATH:/path/to/toolchain/bin ./mach build --android
cd ports/android
ANDROID_SDK=/path/to/sdk make install
</pre>

Note: Building Servo will take a considerable amount of time. 

=== Launch Servo ===

Once the build is successful, launch Servo using this command.
<pre>
./mach run tests/html/about-mozilla.html
</pre>

[[File:servo.png]]

== Project Description ==

The [http://html.spec.whatwg.org/multipage/webstorage.html#webstorage 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. It supports persistent data storage, similar to cookies but with a greatly enhanced capacity and no information stored in the 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 window level. The following JavaScript code can be used on browsers to trigger web storage behaviour:

'''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>

As part of our [https://github.com/servo/servo/wiki/Storage-student-project project], we have to implement this 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>

== Implementation ==

For the OSS project, we had to complete the initial step of the project i.e. create the Storage interface and its stub implementation.

We made the following changes:

* Created a new file called [http://github.com/nkdalmia/servo/tree/master/components/script/dom/webidls Storage.webidl] under the folder '''''components/script/dom/webidls.'''''

* Added the method definitions in the above interface file.

* Created another file called [http://github.com/nkdalmia/servo/tree/master/components/script/dom storage.rs] under the specified folder '''''components/script/dom.'''''

* Added constructor for Storage object and stub implementations of the methods defined in the above mentioned interface file.

* Added our module entry in the file ''''' components/script/lib.rs ''''' so that our files are compiled as part of the Servo build.

* Built the Servo once again and verified that the Servo browser was launching correctly.

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

* 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.

== Further Readings ==

Design and Architecture of Servo: http://github.com/servo/servo/wiki/Design/ 
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/>