We're looking for more developers. Want to contribute? Join the Mailing List and introduce yourself, or contact Bruce Damer directly.
Latest News
ALife XII CompOrigins call for papers.

From The EvoGrid: The Evolution Technology Grid

Contents 1 General Design 2 GET 2.1 parameters 2.2 history 2.3 statistics 2.4 scores 3 PUT 3.1 parameters 3.2 history 3.3 statistics 3.4 scores 4 Future Developments

General Design

The Simulation Manager is implemented as JSON transferred over HTTP requests. This uses GET and PUT to retrieve or submit information, with any information not in the URL to be in HTTP headers.

All requests start from a base URL. On the development server, this is

 http://wizarth.is-a-geek.org/development/evogrid/

This URL uses Apache mod_rewrite to convert to

 http://wizarth.is-a-geek.org/development/evogrid/index.php

and is just shortened for neatness. In the Alpha 10-01 VM Images, the path is

 http://192.168.230.2/index.php

When accessed directly, the base URL produces a human readable status page.

The URL used to access a resource follows a pattern of

 [base_url]/[simulation id]/[property]

Additionally, [simulation id] can be the magic word "pending". Property can be

• parameters
• history
• statistics
• scores

For example:

 http://192.168.230.2/index.php/pending/parameters

Providing a incorrectly formatted simulation id will return a HTTP 400 - Bad Request.

Redirect means - Provides a HTTP 302 response, and provides a Location: header.

When using a GET request, if the data is not available, returning HTTP 404 is the standard response.

See Prototype2009: Data Formats for the JSON used in these requests.

GET

parameters

• pending - Will redirect to a simulation id that hasn't been simulated
• simulation id - Will provide the parameters for the specific simulation

history

• pending - Will redirect to a simulation with a history but no statistics
• simulation id - Will provide the history for the specific simulation

statistics

• pending - Returns HTTP 400, pending is not valid for statistics
• simulation id - Will provide the statistics for the specific simulation

scores

• pending - Requires the X-Search-Score header be included in the request. This will return the scores for a simulation that has scores, but not the X-Search-Score
• simulation id - Will provide the scores for the specific simulation

PUT

Unless specified, use of pending will return HTTP 400.

parameters

• pending - Will submit the simulation parameters as a new simulation

All other parameters (like a simulation id) will return HTTP 400.

history

• simulation id
  • If simulation already has a history, returns HTTP 403 (Forbidden).
  • Otherwise, history is stored

statistics

• simulation id
  • If simulation doesn't have a history, returns HTTP 403 (Forbidden)
  • Store statistics, discarding duplicates of already know statistics
    • While in development - If statistic name is not recognized, it is added as a new type of statistic

scores

• simulation id
  • If simulation doesn't have a history, returns HTTP 403 (Forbidden)
  • Store scores, discarding duplicates of already known scores

Future Developments

• Require identifiers/accounts for PUT actions, for logging and security (prevent poisoning).
• Use multiple sources for all processing that is farmed out (prevent poisoning).
• Break searches separately from scores.
  • Have searches require sets of scores, specified server side.
  • Concept: /pending/search/search-identifier rather then X-Search-Score ?
• PUT /pending/parameters will include which search it's being submitted for.
• GET /[simulation id]/ (without parameters/history/statistics/scores/etc) will return a human formatted status page for that simulation
• Human readable pages could use a microformats concept to remain machine parsable?