Web Services & Javascript: Difference between revisions
Line 12: | Line 12: | ||
== Server Side in C == | == Server Side in C == | ||
=== | === Page Setup Query === | ||
To minimize the round trips between the web server and the jQuery client, the initial query to the server returns quite a bit of information, which can be broken into two main parts: | |||
==== What is the user's state ==== | |||
===== Organism/assembly/position ===== | |||
===== Various UI preferences ===== | |||
==== What data is available to the user ==== | |||
===== What organisms/assemblies ===== | |||
===== What tracks ===== | |||
===== What links in the toolbar ===== | |||
==== List of displayed tracks ==== | |||
=== Queries to Fetch Data for Genomic Regions === | === Queries to Fetch Data for Genomic Regions === | ||
==== Item list ==== | |||
==== Summary/samples ==== | |||
==== "Browser" query ==== | |||
===== Image ===== | |||
===== Map box ===== | |||
List of items in non-dense tracks with just enough info to generate the map-boxes. | |||
==== Queries to See What Data Is Available ==== | |||
===== What Organisms/Assemblies given user ===== | |||
===== What Tracks given user ===== | |||
===== Track description ===== | |||
===== Track metadata ===== | |||
=== Queries to Fetch Data for One Item === | === Queries to Fetch Data for One Item === |
Revision as of 19:17, 4 March 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
The overall architecture is based on the flow of data through server side scripts in C at genome.ucsc.edu into Javascript-controlled web pages. The major objects in the system include (some of which have expressions both in the C and the Javascript side) include "user," "dataSource," "genomeAssembly," "track," "item," and "relationship." The user object handles passwords and other security, and the user interface settings. A dataSource represents a place that the system queries for live data. It may include a file or data base on the server, a remote SQL database or file set, a web site that the C scripts know how to query via a web-services interface of some sort, or the user's custom tracks. A genomeAssembly includes a particular genome assembly and a NCBI taxon number. A track is conceptually just a table that _may_ include genome position fields that are hooked to a genome assembly. Tracks may be implemented in a variety of ways, not necessarily as SQL tables. An item is conceptually a row in a track table. A relationship links together fields in the track/table rows.
Abstract notion of a data track
Server Side in C
Page Setup Query
To minimize the round trips between the web server and the jQuery client, the initial query to the server returns quite a bit of information, which can be broken into two main parts:
What is the user's state
Organism/assembly/position
Various UI preferences
What data is available to the user
What organisms/assemblies
What tracks
What links in the toolbar
List of displayed tracks
Queries to Fetch Data for Genomic Regions
Item list
Summary/samples
"Browser" query
Image
Map box
List of items in non-dense tracks with just enough info to generate the map-boxes.