GAIA Site Layout

It is assumed that a user gaia will exist and that the GAIA software will be stored in the ~gaia home directory. Listed below are the directories used, with comments about important files contained in them. The URL through which they are accessed is given in square brackets.

~/public_html [/]

The base directory for all web accesses (ie Apache's DocumentRoot directory).

~/public_html/dtd [/dtd]

Data type definition files for XML.

~/public_html/js [/js]

JavaScript libraries and functions. Access with .js extension. For ones generated by PHP omit the .php extension.
GAIA and mirror configuration information, written out as a JavaScript object.

~/public_html/img [/img]

General purpose images, flags to indicate mirror locations, etc.

tip Cannot call the directory icons since most Apache installations use the URL /icons for Apache's own use (eg. when generating directory listings).

~/public_html/inc [ not accessible ]

PHP include files. Accessible to PHP but not accessible via HTTP.

~/public_html/rest [/rest_html, /rest_json, /rest_mat, /rest_xml]

REST web services directory.

Script to handle the case when an image cannot be loaded. Requires type (thumbnail | keogram), channel_id and date. Output is an XML document containing the new URL, and mirror_id. mirror_id=0 represent the fallbck URL. mirror_id=-1 represents the missing image location.

Possible structure for REST web services

Below is a possible scheme. It assumes the 'intermediate' XML documents output data with xlink attributes.

/rest/project/norstar/gill/557.7 nm

/rest/site/gill/norstar/557.7 nm

/rest/mirror/1   or   /rest/mirror/
bubble Yuck - spaces in URL are bad - need abbreviated name for data channel, or something without spaces. Alternatively we map spaces to underscore and disallow underscores in the name (better, not great). Otherwise we use non-obvious numbers.

bubble If we allow different methods to find data (which seems reasonable) we can then end up with different paths to the same data, which isn't RESTful. Should a redirect header be issued, so that a request for /rest/site/gill/norstar/557.7 nm is redirected to /rest/project/norstar/gill/557.7 nm? It might then mean the client would not need to fetch new data for that request. Is that more RESTful?

bubble How do we implement geographic searches? That is much harder to describe, so perhaps query parameters are not unreasonable? (/rest/geolocate?latitude=69&longitude=23&distance=300km ?)

<summary_plot_dir> [/summary_plots ?]

Directory where summary plots are stored. Need not be inside the gaia user directory; location configurable for each mirror via server_config.php. For tarred images use Apache's ErrorDocument directive to call a PHP script which returns a 301 Moved Permanently status to redirect the browser to the cached area (but only after untarring the images).

warning summary_plots is too long, it will be appearing in every data image! We need a shorter name.

tip When untarring may wish to consider using Apache's mod_asis module, and attach HTTP headers to the images so that they can be sent 'as is', which may give performance benefits.

<image_cache> [/tmp ?]

Directory where untarred and colourised images should be stored. It is possible browsers may return here for images after they have been deleted. In this case use essentially the same ErrorDocument as for /summary_plots, but maybe the return status should be 302 Moved Temporarily?

warning Keep separate from <summary_plot_dir> otherwise there is a risk tmpwatch will delete wanted images.

Topic revision: r5 - 2007-02-02 - 23:13:43 - SteveMarple
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback