[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[TASS] Proposal for a second TASS Database.



I'd like to set up a second publicly accessible TASS database.
This would be an "experimental" database as opposed to the
"production" database at rit.edu.

This new database's main purpose would be to advance
the state of the art in tass databases, test new software, operational
methods and so on.  Yes I could set one up in my house (I have) but
1) This work should be done in public where we have real users and
and real data.  2) The TASS database is becoming popular so there
may now be a few more people willing to work on it.  We need a place
to serve as a focus for a collective effort.

I don't see this as competing with or duplicating Michael's efforts.
What I hope will happen is that as the experimental database evolves
Michael will adopt features that he thinks are useful, stable and
well tested for use in the production database.  A few features I'd
like to see developed:

  1) Direct entry of new observations.  Currently observers FTP or
  snail mail CDs with star lists to Michael who every few months
  updates the database in a big off-line batch process.  I'd like
  to try for a direct near real-time model where observers transmit
  data directly to the TASS Database over the Internet.

  2) Use of Postgres' special features like user defined data types
  and functions and built-in geometric operations.

  3) Automated synchronization of replicated data tables.  A user
  could have a local copy of the database and make changes to either
  the local or central copy.  At some point the changes are synchronized.
  (this could be one method to implement #1 above?)

  4) Hold data from the Mk IV, Mk III and possibly other systems doing
  follow up work on TASS objects.


There is more but you get the idea.  You don't want to do the above
to a production database.  Not without "real world" testing.

Having an experimental database also allows us to, experiment.
We would have no problem re-building a database weekly if need
be to test out new catalog matching algorithms or to fix dumb
errors (like that threshold being set at 1 which I will have
to take credit for.)

Having an __publiclyaccessible__ experimental database lets us
divide up the work.  For example It would not take me that much
time to modify the star matching algorithm but I doubt I'd be able
to systematically test which of several algorithms is best.  Someone
else would be better at that

The above is directed at the database but I'd like to see us use in
general a two tiered software development model.  That is we have one
"stable" or "production" system and one "experimental" system.  The
idea is that you use both systems in parallel to some degree.  We have
been using what I call a "replacement" model. where we just start using
a new software version and discard the old one.

I'd do this all myself.  I may still do it, except I am lacking a fast
full time connection to the Internet.  I can get one but my wife thought
we have better uses for the $80.00 per month cost of a DSL Internet
connection.  Until I win that argument I'll have to go begging -- does
anyone have a computer on the Internet that could host an experimental
database?  Just about anything will do.  A PC, Sun SPARC or whatever
the key requirement is a fast Internet connection.  I or others can do
the day to day operation of the system remotely.

I made a similar proposal a while back but must not have made a good
enough answer to the question "Why do we need this?".  Maybe this answer
is better.

A related issue - I have a few spare computer parts these could be
contributed to the above system or if someone on Tom's list of six
Mk IV sites needs to set up a dedicated computer and needs parts for
that.
--
  Chris Albertson

  calbertson@logicon.com                  Voice: 626-351-0089  X127
  Logicon, Pasadena California            Fax:   626-351-0699