Web Services & Javascript: Difference between revisions
(New page: We're thinking of reworking the genome browser so that Javascript is responsible for the layout of the page at a high level rather than the C scripts on the server. As part of this we'll b...) |
No edit summary |
||
Line 1: | Line 1: | ||
== Introduction and Motivation == | |||
We're thinking of reworking the genome browser so that Javascript is responsible for the layout of the page at a high level rather than the C scripts on the server. As part of this we'll be moving the C scripts to more of a web-services oriented architecture, where they'll be returning information in JSON rather than in HTML and GIF images. For the near term at least they probably will return GIF images as well. The goal of this rearchitecting is to make it easier to be more interactive, and to take advantage of the good Javascript user-interface (UI) oriented libraries like jQuery. | We're thinking of reworking the genome browser so that Javascript is responsible for the layout of the page at a high level rather than the C scripts on the server. As part of this we'll be moving the C scripts to more of a web-services oriented architecture, where they'll be returning information in JSON rather than in HTML and GIF images. For the near term at least they probably will return GIF images as well. The goal of this rearchitecting is to make it easier to be more interactive, and to take advantage of the good Javascript user-interface (UI) oriented libraries like jQuery. | ||
As is often the case with software development, the demon is in the details. Nonetheless it is helpful to have a clear, simple high level design to start with - to keep at least the messy details in one location of the code from breeding and exponentially multiplying with messy details in other locations.... | As is often the case with software development, the demon is in the details. Nonetheless it is helpful to have a clear, simple high level design to start with - to keep at least the messy details in one location of the code from breeding and exponentially multiplying with messy details in other locations.... | ||
== Architectural Overview == | |||
=== Abstract notion of a data track === | |||
== Server Side in C == | |||
=== Queries to See What Data Is Available === | |||
=== Queries to Fetch Data for Genomic Regions === | |||
=== Queries to Fetch Data for One Item === | |||
=== User Settings - The Cart === | |||
== Client Side in Javascript == | |||
=== Displaying Tracks === | |||
=== Mani |
Revision as of 18:58, 24 February 2009
Introduction and Motivation
We're thinking of reworking the genome browser so that Javascript is responsible for the layout of the page at a high level rather than the C scripts on the server. As part of this we'll be moving the C scripts to more of a web-services oriented architecture, where they'll be returning information in JSON rather than in HTML and GIF images. For the near term at least they probably will return GIF images as well. The goal of this rearchitecting is to make it easier to be more interactive, and to take advantage of the good Javascript user-interface (UI) oriented libraries like jQuery.
As is often the case with software development, the demon is in the details. Nonetheless it is helpful to have a clear, simple high level design to start with - to keep at least the messy details in one location of the code from breeding and exponentially multiplying with messy details in other locations....
Architectural Overview
Abstract notion of a data track
Server Side in C
Queries to See What Data Is Available
Queries to Fetch Data for Genomic Regions
Queries to Fetch Data for One Item
User Settings - The Cart
Client Side in Javascript
Displaying Tracks
=== Mani