GMOD Developer's Guide

From GMOD
Revision as of 15:40, 5 April 2007 by Bosborne (Talk | contribs)

Jump to: navigation, search

This page or section needs to be edited. Please help by editing this page to add your revisions or additions.


This is the GMOD developer's guide

Favored Platforms

Server Side

  • The following environment variables should be set:
    • GMOD_ROOT
    • CHADO_DB_NAME
    • CHADO_DB_USERNAME
    • CHADO_DB_PASSWORD
    • CHADO_DB_HOST
    • CHADO_DB_PORT
  • OS: any of Linux/BSD, Solaris, OSX.
    Windows: optional as cost/benefit less favorable.
  • Web Server: all of
    • Apache
      • With Modperl 1.3, temporarily; need to migrate to Modperl 2.0 (currently broken) or CGI soon.
      • Allen, Ken to investigate effort required to port their apps to ModPerl 2.0 or CGI.
    • TomCat 4.1 (auxiliary Web server to support server-side Java/JSP)
  • Languages: all of
    • Perl 5.6.1 or higher
    • Java 1.4
  • DBMS: PostgreSQL 7.3
  • Compilers: gcc on Solaris
  • Libraries: Perl bundle; requires some C libraries
  • Hardware:
    • Recommendations based on current MODs to be determined
    • Minimum: 20GB disk, 512 MB ram, 1.8 GHz Pentium or equiv. Client or server.

    Client Side

    OS: Linux, Windows, Mac OSX Browser: any of Mac IE, Win IE, Netscape. Which versions within these? Fly and worm will analyze server logs to determine largest market segments. How to test?


    Server Side Directory Structure

  • $GMOD_HOME=/usr/local/gmod/ (default -- set before installing)

    bin/ -- all scripts & executable
    Prefix all executables with 2-3 letter app prefix
    sbin/ -- system binaries that may do dangerous things
    web/
    htdocs/
    db
    cgi-bin/
    appname
    webapps/
    appname
     
    conf/ -- all configuration files (attr/value format)
    gmod.conf always source this first; global site params
    db.conf
    one for each datasource at the installation
    server, port, DB, login, password,
    banner/site-specific page config info
    optionally source one of these after gmod.conf
    according to "db" URL param
    Perl: use CPAN INI parser to load
    data/ -- inputs and outputs; operator writable
    appname
    lib/
    appname or shared library
    Perl plugins, jar files.
    doc/
    appname
    log/
    examples/
    appname
    src/
    appname

  • $CLASS_PATH := $GMOD_HOME/lib[/app]
  • Suggested CGI Parameter Names:
    • db=short symbolic name of datasource (MOD), used to look up conf file
    • class=object class within db to search
    • id=unique primary key
    • name=human readable, possibly ambiguous string
  • What if multiple DB instances running on same site?
  • Package manager?
  • Testing process: is a goal. "Testing is good" -- LS
    • Developer side
    • Release testing: alpha, beta
    • Installer side
  • </ul>


    Interoperation

  • Support chado schema for genome features
  • Establish clear naming conventions for Chado extension to avoid intermodule conflicts:
    Use namespaces (using PostgreSQL "create schema" or table prefixes?) corresponding to Chado modules. Or will current conventions suffice?
  • Different apps should share portions of schema wherever that makes sense
  • Schema changes need extensive coordination, versioning and testing across all affected apps.
  • Apps are encouraged to be backward compatible with older versions of schema.
  • Need to track which app versions work with which schema versions.
  • Releases:
    • Major (or "public") release is a coordinated release of all apps, with testing.
    • Minor releases / tagged versions as needed by development groups, no guarantee of installable tarball.
  • Schema change coordination manners: notify gmod-schema list of all proposed changes. Is this sufficient (for now?)
  • Support a few standard external reps of data:
    • Sequence feature apps should read/write GenBank & EMBL formats (BioPerl and BioJava handle this). GFF? GTF? BED? GAME? BSML? TIGR add BSML adaptors to BioPerl?
    • Citations: Medline flatfile format
    • Expression: MageML for microarrays
    • Maps: use CMAP tab delimited format. (the new standard :-)
    • Adaptors for chado-DBI and/or chado-XML?
  • AppDB communication:
    • SQL (DBI/JDBC)
    • TIGR developing Perl API for chado: get central dogma model, cv_term2genes, writes
    • UCLA has developed a Perl middleware API (Class::DBI) for Chado
    • BioPerl2chado -- CJM readonly API -- out of date?
    • Chado XML Dumper
  • Bulk dataloading
    • Colin's GAME2chado initializer
    • Chado XML Loader
    • GAME2chadx, chadx2game
    • BSML2chado loader @ TIGR
  • </ul>


    A First GMOD Release would Contain

  • Sample data:
    • Fasta files
    • GenBank files
    • BLAST output
  • Loading tools for sample data
  • Stable chado release
  • gmod-web with "basic" pages
  • Compatible Gbrowse release
  • Apollo (and possibly MANATEE)
  • Other support tools (chadx dumpers and loaders,xxx2chadx translators)
  • DOCUMENTATION (README, INSTALL, CONFIGURATION-HOWTO)
  • </ul>


    Creating a software release

    All software releases for GMOD should conform to a bare minimum standard. First, the package should be easily 'installable.' That is, it should be free of hard coded paths and other machine specific parameters. In addition, the package should contain:

    • A README document
    • A INSTALL document
    • A LICENSE file (containing an open source license; licenses used in GMOD projects include the GNU public license, BSD license, and the Perl artistic license)
    • The source code
    • An appropriate installation method:
      • For Perl modules, use Makefile.PL
      • Perl applications can be installed via Makefile.PL or an install script
      • For Java applications, use a suitable build tool, like Ant
      • For Java servelets that are distributed as war files, the war file should be in a tarball with the above mentioned documentation

    Additionally, the following things are not absolutely required but are strongly advised for GMOD projects:

    • The application should contain a testing suite so that the user can verify proper builds.
    • Packages should contain sample data for testing and trying out the application
    • Including a tutorial for guiding the user on the application's use is a very good idea.
    • For applications that interact with a relational database, it should be able to interact with a Chado database via a database adaptor.

    Finally, a page describing the appication and providing basic information about the application should be provide for www.gmod.org. This page should contain the following information:

    • A brief summary describing the application
    • Links to a demo or screenshot
    • Links to installation documentation
    • Links to downloads
    • Author contact information