Differences between revisions 11 and 12
Revision 11 as of 2007-06-14 19:19:17
Size: 3806
Editor: KarlPinc
Comment: Change page desc to not be just front-ends
Revision 12 as of 2007-07-17 22:30:34
Size: 5828
Editor: KarlPinc
Comment: Add lots of items.
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * Warning system. Current system only reports errors, not warnings. (Warnings can be produced manually, probably.)
 * Revision history for babase with ability to undo changes
 * Warning system. Current system only reports errors, not warnings. (Warnings can be produced manually, probably.)  Have ability to defer warnings for later and an ability to permanently ignore them.
 * Automation of revision history for babase data with ability to undo changes
Line 31: Line 31:

=== Unprioritized ===

 * Looking at the fecal schema and bringing those tables into the offical Babase. That means reviewing the table structure, possible modifications and validation, and documentation. Reviewing the data-loading procedure, perhaps making a view or writing programs to facilitate loading data.

 * Looking at the multi-party interaction data and bringing that data into the offical Babase. That means creating a table structure and validation, fitting it into the existing interaction table structure, and documentation. Creating a data loading procedure, perhaps making a view or writing programs to facilitate loading data.

 * Putting validation into the weather data. I believe the tables are already documented. Reviewing the data loading procedure, perhaps making a view or writing programs to facilitate it.
Line 34: Line 43:
 * Make changes requested by the PPA team to get our custom changes (the "Done But" below) into PPA.  * Make changes requested by the PPA team to get our custom changes (the "Done But" below) into PPA.  (Currently we're waiting on the PPA team for feedback.)
Line 48: Line 57:
 * Don't show things on the screen that the user does not have permission to use.
Line 61: Line 71:
=== Code Management ===

 * Code cleanup and publication.
  * There's some leftover unused code that should be removed.
  * Switch to a different source code management system to keep track of code revisions.
  * Install a web interface into the source code management system so that the public can readily see all versions of the code.
  * Make an official code release so the code can be readily downloaded.

 * A better system for installing the documentation and programs on the website directly from the code repository. The current process is error prone. This will also make it easy for anybody who downloads the code to install and run the website part. And make it easier to put babase on a cd.
Line 63: Line 83:
Someday in the far future.... Make up a block diagram showing the different software pieces and how they talk with each other.  * Finishing the documentation. There's a few small sections leftover from Babase 1.0, and the vocabulary needs reworking in the interactions area.

 * Portable babase. Babase on a cd.

===
Someday in the far future.... ===

 *
Make up a block diagram showing the different software pieces and how they talk with each other.

To Do List

This page records desired enhancements to Babase, and possibly includes priorities. We can also use it to list front-ends under consideration and their pros and cons.

Custom Programs

High priority

  • Warning system. Current system only reports errors, not warnings. (Warnings can be produced manually, probably.) Have ability to defer warnings for later and an ability to permanently ignore them.
  • Automation of revision history for babase data with ability to undo changes
  • Have wwwdiff show line counts when different.
  • In wwwdiff have the "by word, not tabular" mode show individual spaces. Currently when there's a difference in the number of spaces in the 2 files you can't tell by looking at the output. (Whitespace needs to be changed to the non-breaking-space html entity.)

Database

Medium priority

Have REPSTATS and CYCSTATS automatically updated.

Low priority

Psionload error message enhancement

The error messages which are produced by Psionload are a bit raw, and we have some suggestions on a couple of them. I'm sure we'll come up with more as we have only seen a few of the error messages thus far.

{{{ "Error: Pntid *****, Nghid *****, Neighbor after statdate blah blah (dead neighbor)"}}}

  • ---Pntid and Nghid are irrelevant as the file doesn't actually go into

the system, and can't be searched, it can thus be removed.

Also in the Psionload program, it would be helpful if at the beginning of each error message, the name of the focal animal could be displayed. This makes searching for the error to fix it much easier.

Comment: This is all the same problem. The database does not have the focal individual at-hand when the neighbor is inserted. It just has the neighbor row. I can have the DB query itself to find the focal individual to enhance the error messages. Easy, but involves adding extra code each time an error message crops up.

Unprioritized

  • Looking at the fecal schema and bringing those tables into the offical Babase. That means reviewing the table structure, possible modifications and validation, and documentation. Reviewing the data-loading procedure, perhaps making a view or writing programs to facilitate loading data.
  • Looking at the multi-party interaction data and bringing that data into the offical Babase. That means creating a table structure and validation, fitting it into the existing interaction table structure, and documentation. Creating a data loading procedure, perhaps making a view or writing programs to facilitate loading data.
  • Putting validation into the weather data. I believe the tables are already documented. Reviewing the data loading procedure, perhaps making a view or writing programs to facilitate it.

phpPgAdmin

Needs Work

High priority

  • Make changes requested by the PPA team to get our custom changes (the "Done But" below) into PPA. (Currently we're waiting on the PPA team for feedback.)

Medium priority

  • The ability to insert/update/delete the database through views in the same way it can be updated through tables. There are two categories of functionality here, individual row maintanence and bulk uploads.
    • Bulk uploads is useful for the regular addition of data. It can be worked around by using the custom [https://papio.biology.duke.edu/programs/upload/ Upload] program (or by use of the Unix interface, which does allow bulk uploads to views.)

    • Individual row maintance is useful for manual corrections. It can be worked around by using sql to update the database rather than a [wiki:Graphical_user_interface GUI].

Low priority

  • A 'find' feature for the editing and updating of rows.
  • Don't show stuff we don't need to see:
    • Estimated row count column
    • The column with the "Empty" button
  • Have the column headings in the SQL output "stick" on the screen.
  • Making the "Show Statements" option in SQL window checked by default, with the option to uncheck the box.
  • Don't show things on the screen that the user does not have permission to use.

Done But

What's listed here has been done but is waiting for inclusion in the offical phpPgAdmin code.

  • Rapid display of large amounts of information.
    • Text output of query results added
  • The ability to download data directly from a query without having to load the data into a table first.
  • SQL command history.
  • COPY TO support in user-supplied SQL.

Unreleased

What's listed here has been included in the official phpPgAdmin code, but has not yet been released to the public.

Code Management

  • Code cleanup and publication.
    • There's some leftover unused code that should be removed.
    • Switch to a different source code management system to keep track of code revisions.
    • Install a web interface into the source code management system so that the public can readily see all versions of the code.
    • Make an official code release so the code can be readily downloaded.
  • A better system for installing the documentation and programs on the website directly from the code repository. The current process is error prone. This will also make it easy for anybody who downloads the code to install and run the website part. And make it easier to put babase on a cd.

Other TODO

  • Finishing the documentation. There's a few small sections leftover from Babase 1.0, and the vocabulary needs reworking in the interactions area.
  • Portable babase. Babase on a cd.

Someday in the far future....

  • Make up a block diagram showing the different software pieces and how they talk with each other.

ToDo (last edited 2012-04-24 20:44:03 by NikiLearn)

Wiki content based upon work supported by the National Science Foundation under Grant Nos. 0323553 and 0323596. Any opinions, findings, conclusions or recommendations expressed in this material are those of the wiki contributor(s) and do not necessarily reflect the views of the National Science Foundation.