Expertiza_Wiki - User contributions [en]

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

2014-12-04T00:53:22Z

Aprasad3: /* 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 outer Hashmap is used to store requests and values based on the origin of the request i.e. the url it is coming from , therefore every url/origin will have a TreeMap of its own which will maintain the <key , value> pair in a logical fashion. Thus the storage task contains the actual data structure which holds all the values and the Storage.rs will act 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 , one which the storage task creates and loops on to listen onto the request, the other is when the storage object wants to get data from the task , it creates a temp channel on which it listens for reply. 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, therefore by passing the created channel to the page structure it can now be accessed and utilized by the Storage 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. <br/>
2. Generate the corresponding WebIDL bindings - Storage.webidl <br/>
3. Define Storage.rs which has the actual code for creating the storage object. <br/>
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. <br/>
5. Build the servo again. <br/>

=== Use Case Diagram ===
[[File:Use_Case_-_Storage.png‎]]

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

== 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/ <br/>
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ <br/>

== References ==
<references/>

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

2014-12-04T00:50:28Z

Aprasad3: /* 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 outer Hashmap is used to store requests and values based on the origin of the request i.e. the url it is coming from , therefore every url/origin will have a TreeMap of its own which will maintain the <key , value> pair in a logical fashion. Thus the storage task contains the actual data structure which holds all the values and the Storage.rs will act 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 , one which the storage task creates and loops on to listen onto the request, the other is when the storage object wants to get data from the task , it creates a temp channel on which it listens for reply. This is how the message-passing interface has been implemented in the given milestone.

== 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. <br/>
2. Generate the corresponding WebIDL bindings - Storage.webidl <br/>
3. Define Storage.rs which has the actual code for creating the storage object. <br/>
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. <br/>
5. Build the servo again. <br/>

=== Use Case Diagram ===
[[File:Use_Case_-_Storage.png‎]]

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

== 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/ <br/>
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ <br/>

== References ==
<references/>

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

2014-12-04T00:48:39Z

Aprasad3:

== 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 outer Hashmap is used to store requests and values based on the origin of the request i.e. the url it is coming from , therefore every url/origin will have a TreeMap of its own which will maintain the <key , value> pair in a logical fashion. Thus the storage task contains the actual data structure which holds all the values and the Storage.rs will act 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]

== 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. <br/>
2. Generate the corresponding WebIDL bindings - Storage.webidl <br/>
3. Define Storage.rs which has the actual code for creating the storage object. <br/>
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. <br/>
5. Build the servo again. <br/>

=== Use Case Diagram ===
[[File:Use_Case_-_Storage.png‎]]

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

== 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/ <br/>
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ <br/>

== References ==
<references/>

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

2014-11-18T04:43:38Z

Aprasad3: /* Proposed Test Cases */

== Implement Window.sessionStorage ==

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

__TOC__

== Introduction ==

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

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

Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

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

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

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

== Background ==

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

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

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

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

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

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

== Project Description ==

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

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

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

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

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

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

[[File:task.jpg]]

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

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

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

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

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

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

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

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

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

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

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

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

== Data Design ==

=== Data Description ===

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

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

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

== Design Pattern ==

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

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. <br/>
2. Generate the corresponding WebIDL bindings - Storage.webidl <br/>
3. Define Storage.rs which has the actual code for creating the storage object. <br/>
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. <br/>
5. Build the servo again. <br/>

'''Use Case Functionality'''

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

== 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/ <br/>
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ <br/>

== References ==
<references/>

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

2014-11-18T04:41:47Z

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

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

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

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

[[File:task.jpg]]

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

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

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

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

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

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

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

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

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

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

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

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

== Data Design ==

=== Data Description ===

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

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

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

== Design Pattern ==

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

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. <br/>
2. Generate the corresponding WebIDL bindings - Storage.webidl <br/>
3. Define Storage.rs which has the actual code for creating the storage object. <br/>
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. <br/>
5. Build the servo again. <br/>

'''Use Case Functionality'''

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

== 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/ <br/>
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ <br/>

== References ==
<references/>

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

2014-11-18T04:41:33Z

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

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

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

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

[[File:task.jpg]]

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

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

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

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

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

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

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

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

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

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

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

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

== Data Design ==

=== Data Description ===

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

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

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

== Design Pattern ==

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

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. <br/>
2. Generate the corresponding WebIDL bindings - Storage.webidl <br/>
3. Define Storage.rs which has the actual code for creating the storage object. <br/>
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. <br/>
5. Build the servo again. <br/>

'''Use Case Functionality'''

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

== 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/ <br/>
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ <br/>

== References ==
<references/>

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

2014-11-18T04:41:18Z

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

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

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

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

[[File:task.jpg]]

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

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

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

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

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

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

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

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

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

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

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

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

== Data Design ==

=== Data Description ===

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

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

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

== Design Pattern ==

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

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. <br/>
2. Generate the corresponding WebIDL bindings - Storage.webidl <br/>
3. Define Storage.rs which has the actual code for creating the storage object. <br/>
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. <br/>
5. Build the servo again. <br/>

'''Use Case Functionality'''

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

== 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/ <br/>
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ <br/>

== References ==
<references/>

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

2014-11-18T04:40:15Z

Aprasad3:

== Implement Window.sessionStorage ==

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

__TOC__

== Introduction ==

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

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

Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

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

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

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

== Background ==

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

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

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

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

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

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

== Project Description ==

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

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

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

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

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

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

[[File:task.jpg]]

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

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

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

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

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

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

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

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

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

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

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

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

== Data Design ==

=== Data Description ===

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

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

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

== Design Pattern ==

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

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. <br/>
2. Generate the corresponding WebIDL bindings - Storage.webidl <br/>
3. Define Storage.rs which has the actual code for creating the storage object. <br/>
4. Call the receiver via a channel- this is actually used for creating an instance for each unique URL. <br/>
5. Build the servo again. <br/>

'''Use Case Functionality'''

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

== 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/ <br/>
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ <br/>

== References ==
<references/>

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

2014-11-18T04:37:52Z

Aprasad3:

== Implement Window.sessionStorage ==

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

__TOC__

== Introduction ==

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

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

Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

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

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

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

== Background ==

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

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

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

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

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

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

== Project Description ==

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

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

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

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

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

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

[[File:task.jpg]]

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

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

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

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

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

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

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

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

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

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

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

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

== Data Design ==

=== Data Description ===

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

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

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

== Design Pattern ==

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

== UML Diagrams ==

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

'''Steps:'''

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

'''Use Case Functionality'''

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

== 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/ <br/>
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ <br/>

== References ==
<references/>

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

2014-11-18T04:36:55Z

Aprasad3: /* Proposed Test Cases */

== Implement Window.sessionStorage ==

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

__TOC__

== Introduction ==

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

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

Rust’s lightweight task mechanism also promises to allow fine-grained isolation between browser components, such as tabs and extensions, without the need for expensive runtime protection schemes, like operating system process isolation. <ref> https://www.mozilla.org/en-US/research/projects/ </ref>

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

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

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

== Background ==

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

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

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

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

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

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

== Project Description ==

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

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

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

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

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

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

[[File:task.jpg]]

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

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

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

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

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

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

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

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

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

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

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

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

== Data Design ==

=== Data Description ===

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

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

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

== Design Pattern ==

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

== UML Diagrams ==

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

'''Steps:'''

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

'''Use Case Functionality'''

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

== 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/ <br/>
Javascript as Servo's Garbage Collector: http://blog.mozilla.org/research/2014/08/26/javascript-servos-only-garbage-collector/ <br/>

== References ==
<references/>

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

2014-11-11T19:17:01Z

Aprasad3: /* Component Design */

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

== 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-11T19:14:31Z

Aprasad3: /* Component Design */

2014-09-25T22:39:28Z

Aprasad3:

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell<ref name=overview>[http://www.liftweb.net/lift_overview Lift Overview]</ref>

==Background==
Lift is an open source software licensed under an Apache 2.0 license. Lift 2.5 is the latest stable version released and the Lift community has already started development for Lift 3.0. The source code can be found of the GitHub repository.<ref name=github>[https://github.com/lift/framework Lift Source Code]</ref>
Lift borrows from the best of existing frameworks, providing:
*Seaside’s highly granular sessions and security.
*Rails’s fast flash-to-bang.
*Django’s “more than just CRUD is included”.
*Wicket’s designer-friendly templating style.<ref name=wiki>[https://www.assembla.com/spaces/liftweb/wiki/Home Lift Developers' wiki]</ref>

Lift is built on top of the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

== The Scala Programming Language ==

Scala is a statically typed multi-paradigm programming language integrating features of object-oriented and functional languages. It runs on the JVM and is fully interoperable with Java. Scala is equipped with an expressive type system providing a powerful basis for the safe reuse of component abstractions and provides a combination of language mechanisms that make it easy to smoothly add new language constructs as libraries. The resulting language scalability -- as praised in Guy Steele's famous 1998 OOPSLA keynote, is illustrated by Scala's lightweight actor library. Furthermore, Scala syntax supports native XML literals.

==Features of Lift Web Framework ==
* '''LazyLoading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, [http://en.wikipedia.org/wiki/Cross-site_scripting XSS], Direct Object references and URL access

* '''Developer centric:''' Lift apps are fast to build, concise and easy to maintain and can be developed in totally designer friendly way.

* '''Scalable:''' Lift apps are high performance and scale in the real world to handle the high volume of traffic.

* ''' Modular:''' Lift apps can benefit from, easy to integrate, pre built modules<ref name=liftweb>[http://liftweb.net/ Lift Official HomePage]</ref>

== Comparison to Rails ==

=== The View-First Approach ===

Templates in Lift are used for display only and never contain programming logic. Consequently, they can be manipulated by non-programmers with tools such as Dreamweaver. Furthermore, contrarily to Rails, Lift snippets are invoked by the template, and not vice versa. The following template illustrates the view-first approach by invoking the form method in the User snippet using the <lift:snippet> tag. The body of this tag can refer to values bound by the User snippet in the snippet-defined fields namespace.

<pre>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:lift="http://liftweb.net/">
...
<lift:snippet type="user:form" form="POST">
First name <fields:first />
Last name <fields:last />
<fields:submit />
</lift:snippet>
...
</html>
</pre>

Rails' controller-first dispatch mechanism makes the assumption that there is only one piece of logic on the page and the rest is decoration. When a page contains more than one piece of logic (e.g. a shopping cart and an interactive chat), having to choose a single piece of logic make the controller code complicated. This usually require some combination of controller inheritance (move common logic into the superclass of controllers -- e.g. put the shopping cart code in the ApplicationController), moving code from controllers into helpers and models, and the use of partial views.

Finally, the view-first approach allows the templates to easily glue different components together. However, when gluing components gets more complicated (e.g. when dependencies must be satisfied), the simplicity of this approach fails and actual code has to be written.<ref name=viewfirst>[http://stanford.wikia.com/wiki/Project_2:_Lift,_the_Scala_Web_framework View-First Approach]</ref>

=== Long-Lived Closures ===
Lift allows the server application to attach closures to elements rendered in the user interface (e.g. form elements). The following snippet illustrates to usage of such closures.
<pre>
class User {
def form(template: Group) = {
var first, last = ""
bind("fields", template,
"first" --> text("", n => first = n),
"last" --> text("", l => last = l),
"submit" --> submit("Submit", ignore => process(first, last)))
}

def process(first: String, last: String) {
...
}
}
</pre>

The n => first = n and l => last = l anonymous functions are attached to two text inputs. The input Lift passes to these functions is the value of the element. The body of these two functions assign the value of text input to the first and last variables. The ignore => process(first, last) anonymous function is attached to the submit button. In this case, we ignore the argument adequately named ignore because a button doesn't have a value. The body is call another function that could, for instance, store the two names in a database.

To achieve this magic, Lift stores the closures in a map when the component is rendered. Randomly generated strings are used as keys and inserted in the generated HTML elements. When the form is submitted, Lift looks for the closures in the map based on the provided keys and executes them. Note how the first and last variables are captured by the three closures and, consequently, stored between the two request-response cycles.

The advantage of this approach is that snippets can specify what happens when a specific button is pushed rather than having a controller parsing the submitted form and process the parameters extracted from the HTTP request. In essence, Lift allows you to specify server-side actions corresponding to user actions when the form is rendered rather than processing the results to figure out what actions the user performed during the next request. This reduces the need for magic constants used to map actions between the rendered view and controllers in other frameworks. In Rails, you might create a form with two buttons labeled 'Buy Now' and 'Buy Later' and then compare the submit parameter to 'Buy Now' and 'Buy Later' in the controller to determine the appropriate action. In Lift, this can be done with two different bindings in the render function.<ref name = closure>[http://stanford.wikia.com/wiki/Project_2:_Lift,_the_Scala_Web_framework Closures]</ref>

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# [http://en.wikipedia.org/wiki/Object-relational_mapping ORM]: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code><ref name=sbt>[http://en.wikipedia.org/wiki/SBT_(software) SBT]</ref>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

Setup Video Tutorial : [http://www.youtube.com/watch?v=qRIiUUKA2Mw link]

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Framework Comparison ==

{| class="wikitable"
|-
!
! Lift
! Rails
! Play
|-
| Scaffolding
| No
| Yes
| Yes
|-
| Design Pattern
| MVVM
| MVC
| MVC
|-
| Programming language
| Scala
| Ruby
| Java
|-
| Template language
| HTML5
| ERB/HAML
| Groovy/Japid
|-
| Dynamic Typing
| No
| Yes
| No
|-
| Admin Generator
| Yes
| Yes
| No
|}

== Advantages ==
# Binding server side state to users' sessions is incredibly powerful. Each user can have a living representation in the server that talks to other users' representations.<ref name=adv>[http://stanford.wikia.com/wiki/Project_2:_Lift,_the_Scala_Web_framework Lift Project]</ref>
# Built-in Comet support possibly the best Comet support in web frameworks. Pushing data to the browser is as simple as calling partialUpdate or asking for a full re-rendering of the component. Updates of multiple components are automatically serialized in a unique connection.
# Long-live closures simplify form processing and can be used to create complex wizards.
# View-first approach helps with 'Lean Controller, Fat Model'.
# Server state machines support for models, including timeouts. For instance, we can use a machine to specify that after three days without confirmation, a new account has to be deleted. Consequently, there is no need for cron and script/runner type solutions in Rails. Instead of imperatively stating what maintenance operations to do; state what rules to enforce and it is automatically done when necessary.

== Disadvantages ==

# Moving state to the server comes with all disadvantages discussed in class. That being said, various remote actors libraries are currently being developed and would permit actors living in different JVMs (running possibly on different machines) to communicate between each others seamlessly. <ref name=adv>[http://stanford.wikia.com/wiki/Project_2:_Lift,_the_Scala_Web_framework Lift Project]</ref>Furthermore, it is often possible to architect an application such that loosely coupled components can live on different machines -- it is definitely possible with the stock trading application we will present during our in-class presentation.
# Terrible API (i.e. badly chosen names, confusing domain model) and no documentation at all (the Scala documentation is OK, though).
# Despite the fact that the API is stabilizing (unfortunately?), most of the tutorials are outdated.
# Routing is a nightmare for no infrastructure is available.
# Despite the fact that we can't move logic from snippets to templates, it is possible to move XHTML from templates to snippets. It is not always clear where the view has to be. Is a snippet a controller or a dynamically generated view? Is there actually a difference between the two?

== Get Started ==

The Lift Cookbook is the best place to start with using the Lift Framework.
[http://cookbook.liftweb.net/ CookBook]

== References ==
<references></references>

CSC/ECE 517 Fall 2014/ch1a 4 wl

2014-09-25T22:38:44Z

Aprasad3: /* Framework Comparison */

WEB DEVELOPMENT USING LIFT
==Introduction==
Lift is a web framework designed to make the most powerful techniques easily accessible while keeping the overall framework simple and flexible. Lift has picked some of the best ideas from a number of other frameworks while creating some of it's own novel ideas. This combination of solid foundation and new techniques makes Lift a powerful framework. The clear separation of presentation content and logic based on the concept of Model View Controller pattern is one of the key strengths of the framework.

"Lift is the kind of web framework that enables you as a developer to concentrate on the big picture. Strong, expressive typing and higher-level
features like the built-in Comet support allow you to focus on innovating instead of the plumbing." -- Novell<ref name=overview>[http://www.liftweb.net/lift_overview Lift Overview]</ref>

==Background==
Lift is an open source software licensed under an Apache 2.0 license. Lift 2.5 is the latest stable version released and the Lift community has already started development for Lift 3.0. The source code can be found of the GitHub repository.<ref name=github>[https://github.com/lift/framework Lift Source Code]</ref>
Lift borrows from the best of existing frameworks, providing:
*Seaside’s highly granular sessions and security.
*Rails’s fast flash-to-bang.
*Django’s “more than just CRUD is included”.
*Wicket’s designer-friendly templating style.<ref name=wiki>[https://www.assembla.com/spaces/liftweb/wiki/Home Lift Developers' wiki]</ref>

Lift is built on top of the Scala programming language. Scala is a relatively new language which compiles to Java bytecode and runs on the JVM. Scala was developed by Martin Odersky. Since lift is built on Scala, the vast ecosystem of Java libraries can be leveraged for the web development like any other Java based web framework. Lift also uses the extensive XML library support and processing capabilities of the Scala language.

== The Scala Programming Language ==

Scala is a statically typed multi-paradigm programming language integrating features of object-oriented and functional languages. It runs on the JVM and is fully interoperable with Java. Scala is equipped with an expressive type system providing a powerful basis for the safe reuse of component abstractions and provides a combination of language mechanisms that make it easy to smoothly add new language constructs as libraries. The resulting language scalability -- as praised in Guy Steele's famous 1998 OOPSLA keynote, is illustrated by Scala's lightweight actor library. Furthermore, Scala syntax supports native XML literals.

==Features of Lift Web Framework ==
* '''LazyLoading:''' Lift supports lazy loading of a snippet. This is useful when a snippet may take a long time to render, but it is required to return the page to the browser quickly.

* '''Parallel Page rendering:''' Executing multiple snippets in parallel is possible in Lift. Multiple jobs or processes can be spawned and run in parallel. However only when all the tasks or jobs are complete the final page render is sent back to the browser.

* '''Comet and Ajax support:''' Comet along with Ajax supports the asynchronous updates from user to the server or from server back to the user.

* '''Wiring:''' The relationship between different elements on a page is defined through Lift Wiring. When any element on a page changes, the dependent items are displayed on the next HTTP response.

* '''Security:''' Lift apps are not vulnerable to the common security concerns. Lift has built-in safeguards to combat vulnerabilities like Injection, [http://en.wikipedia.org/wiki/Cross-site_scripting XSS], Direct Object references and URL access

* '''Developer centric:''' Lift apps are fast to build, concise and easy to maintain and can be developed in totally designer friendly way.

* '''Scalable:''' Lift apps are high performance and scale in the real world to handle the high volume of traffic.

* ''' Modular:''' Lift apps can benefit from, easy to integrate, pre built modules<ref name=liftweb>[http://liftweb.net/ Lift Official HomePage]</ref>

== Comparison to Rails ==

=== The View-First Approach ===

Templates in Lift are used for display only and never contain programming logic. Consequently, they can be manipulated by non-programmers with tools such as Dreamweaver. Furthermore, contrarily to Rails, Lift snippets are invoked by the template, and not vice versa. The following template illustrates the view-first approach by invoking the form method in the User snippet using the <lift:snippet> tag. The body of this tag can refer to values bound by the User snippet in the snippet-defined fields namespace.

<pre>
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:lift="http://liftweb.net/">
...
<lift:snippet type="user:form" form="POST">
First name <fields:first />
Last name <fields:last />
<fields:submit />
</lift:snippet>
...
</html>
</pre>

Rails' controller-first dispatch mechanism makes the assumption that there is only one piece of logic on the page and the rest is decoration. When a page contains more than one piece of logic (e.g. a shopping cart and an interactive chat), having to choose a single piece of logic make the controller code complicated. This usually require some combination of controller inheritance (move common logic into the superclass of controllers -- e.g. put the shopping cart code in the ApplicationController), moving code from controllers into helpers and models, and the use of partial views.

Finally, the view-first approach allows the templates to easily glue different components together. However, when gluing components gets more complicated (e.g. when dependencies must be satisfied), the simplicity of this approach fails and actual code has to be written.<ref name=viewfirst>[http://stanford.wikia.com/wiki/Project_2:_Lift,_the_Scala_Web_framework View-First Approach]</ref>

=== Long-Lived Closures ===
Lift allows the server application to attach closures to elements rendered in the user interface (e.g. form elements). The following snippet illustrates to usage of such closures.
<pre>
class User {
def form(template: Group) = {
var first, last = ""
bind("fields", template,
"first" --> text("", n => first = n),
"last" --> text("", l => last = l),
"submit" --> submit("Submit", ignore => process(first, last)))
}

def process(first: String, last: String) {
...
}
}
</pre>

The n => first = n and l => last = l anonymous functions are attached to two text inputs. The input Lift passes to these functions is the value of the element. The body of these two functions assign the value of text input to the first and last variables. The ignore => process(first, last) anonymous function is attached to the submit button. In this case, we ignore the argument adequately named ignore because a button doesn't have a value. The body is call another function that could, for instance, store the two names in a database.

To achieve this magic, Lift stores the closures in a map when the component is rendered. Randomly generated strings are used as keys and inserted in the generated HTML elements. When the form is submitted, Lift looks for the closures in the map based on the provided keys and executes them. Note how the first and last variables are captured by the three closures and, consequently, stored between the two request-response cycles.

The advantage of this approach is that snippets can specify what happens when a specific button is pushed rather than having a controller parsing the submitted form and process the parameters extracted from the HTTP request. In essence, Lift allows you to specify server-side actions corresponding to user actions when the form is rendered rather than processing the results to figure out what actions the user performed during the next request. This reduces the need for magic constants used to map actions between the rendered view and controllers in other frameworks. In Rails, you might create a form with two buttons labeled 'Buy Now' and 'Buy Later' and then compare the submit parameter to 'Buy Now' and 'Buy Later' in the controller to determine the appropriate action. In Lift, this can be done with two different bindings in the render function.<ref name = closure>[http://stanford.wikia.com/wiki/Project_2:_Lift,_the_Scala_Web_framework Closures]</ref>

== Lift Web Framework ==
<div class="center"> [[File:LiftArchDiagram.jpg]] </div>

=== Components ===
# LiftCore: This is the web processor of the framework which handles the following functions.
## Request/Response
## Rendering Pipeline
## Invoking User Functions
# LiftRules : Lift Configuration
# LiftSession: Inherent Session State.
# S: stateful context for request/response lifecycle.
# SiteMap: contains web pages for the lift application.
# SHtml: helper functions for XHtml.
# Views: Views as XML content. Allows composing views from not only html files but other contexts too.
# LiftResponse: Abstraction of response sent to the client.
# Comet: allows sending asynchronous content to browser.
# [http://en.wikipedia.org/wiki/Object-relational_mapping ORM]: A specialized library.
# HTTP Auth: provides control over authentication model.
# JS API: JavaScript abstraction layer.<ref name=explore>[http://exploring.liftweb.net/master/index-9.html Exploring Lift Framework]</ref>

== Getting Started ==

=== Set Up on Eclipse ===

# Download “Scala IDE for Eclipse” : http://scala-ide.org/
# Install plugin in Eclipse from this update site : http://download.scala-ide.org/sdk/helium/e38/scala211/stable/site
# Once the plugin is installed restart Eclipse
# Install sbteclipse by adding the following to projects/plugins.sbt in your Lift Project: <code> addSbtPlugin("com.typesafe.sbteclipse" % "sbteclipse-plugin" % "2.5.0") </code><ref name=sbt>[http://en.wikipedia.org/wiki/SBT_(software) SBT]</ref>
# You can then create Eclipse project files (.project and .classpath) by entering the following into the SBT prompt: <code> eclipse </code><ref name=cookbook>[http://cookbook.liftweb.net/ The Lift Cookbook]</ref>

Setup Video Tutorial : [http://www.youtube.com/watch?v=qRIiUUKA2Mw link]

== Basic Web Application Structure ==

=== Step 1: Making a SiteMap entry ===

Every page on the site needs a SiteMap entry.
<pre>
def sitemap(): SiteMap = SiteMap(
Menu("Home") / "index",
Menu("Second Page") / "second"
)
</pre>

=== Step 2: Creating the view ===
Create an HTML file that corresponds to the sitemap entry.

<pre>
<meta content="text/html; charset=UTF-8" http-equiv="content-type">
<title>Home</title>

<div id="main" class="lift:surround?with=default&at=content">
<div>
Hi, I'm a page that contains the time:
<span class="lift:TimeNow">??? some time</span>.
</div>

<div>
And a button: <button class="lift:ClickMe">Click Me</button>.
</div>
</div>

</pre>

=== Step 3 : Creating the Snippet ===

A snippet can be thought of as a controller which has rules for transforming the section of your template.

<pre>
package code
package snippet

import net.liftweb._
import util._
import Helpers._

object TimeNow {
def render = "* *" #> now.toString
}
</pre><ref name=simplylift>[http://simply.liftweb.net/ Simply Lift]</ref>

== Advantages ==
# Binding server side state to users' sessions is incredibly powerful. Each user can have a living representation in the server that talks to other users' representations.<ref name=adv>[http://stanford.wikia.com/wiki/Project_2:_Lift,_the_Scala_Web_framework Lift Project]</ref>
# Built-in Comet support possibly the best Comet support in web frameworks. Pushing data to the browser is as simple as calling partialUpdate or asking for a full re-rendering of the component. Updates of multiple components are automatically serialized in a unique connection.
# Long-live closures simplify form processing and can be used to create complex wizards.
# View-first approach helps with 'Lean Controller, Fat Model'.
# Server state machines support for models, including timeouts. For instance, we can use a machine to specify that after three days without confirmation, a new account has to be deleted. Consequently, there is no need for cron and script/runner type solutions in Rails. Instead of imperatively stating what maintenance operations to do; state what rules to enforce and it is automatically done when necessary.

== Disadvantages ==

# Moving state to the server comes with all disadvantages discussed in class. That being said, various remote actors libraries are currently being developed and would permit actors living in different JVMs (running possibly on different machines) to communicate between each others seamlessly. <ref name=adv>[http://stanford.wikia.com/wiki/Project_2:_Lift,_the_Scala_Web_framework Lift Project]</ref>Furthermore, it is often possible to architect an application such that loosely coupled components can live on different machines -- it is definitely possible with the stock trading application we will present during our in-class presentation.
# Terrible API (i.e. badly chosen names, confusing domain model) and no documentation at all (the Scala documentation is OK, though).
# Despite the fact that the API is stabilizing (unfortunately?), most of the tutorials are outdated.
# Routing is a nightmare for no infrastructure is available.
# Despite the fact that we can't move logic from snippets to templates, it is possible to move XHTML from templates to snippets. It is not always clear where the view has to be. Is a snippet a controller or a dynamically generated view? Is there actually a difference between the two?

== Get Started ==

The Lift Cookbook is the best place to start with using the Lift Framework.
[http://cookbook.liftweb.net/ CookBook]

== Framework Comparison ==

{| class="wikitable"
|-
!
! Lift
! Rails
! Play
|-
| Scaffolding
| No
| Yes
| Yes
|-
| Design Pattern
| MVVM
| MVC
| MVC
|-
| Programming language
| Scala
| Ruby
| Java
|-
| Template language
| HTML5
| ERB/HAML
| Groovy/Japid
|-
| Dynamic Typing
| No
| Yes
| No
|-
| Admin Generator
| Yes
| Yes
| No
|}

== References ==
<references></references>