Present: Gareth, Pat, Nicole, Kai; Dana, Paul, Amy (phone), Karen (later); Stephan, Bryan

  1. Uniqueness of e-mail address in User Database: agreement we wanted this.
    • Is it in an existing MR?
    • Require it to be unique in the DB?
      • Would require cleanup of existing database.
    • In the merging before, we did not check for uniqueness of email addresses.
    • Is this worth a campaign similar to what we did with duplicate people?
      • One complication: professor and students all use prof's address. Just one case in BOS known to Kai.
    • ** Stephan to find out the size of the problem (how many dupes)?
    • ** Dana to follow up on status of MR.
  2. Status of Global ID (Paul); cf. UserDatabasePlanOfRecordT32009
    • We're still using ID (not GlobalID) in (DSS?); what's the status?
    • This is supposedly in the plan of record; should be done by end of trimester (Jan 30, 2010).
  3. Changes to proposal XML? Separate group (of mostly the same people).
  4. How is the BOS/PST merging progressing?
    • Plan is to blitz on this next week. Hoping prior experience (with 300 users, not much time needed) reflects what will happen.
    • Do we need to change the interface between DSS and BOS then?
      • Can pass the ID now, but usernames will continue to work for now.
      • Once OpenSky starts using GlobalID, can we use that instead? Yes, we can switch when they are done.
  5. Database Replication at sites
    • EVLA assumed this was always the plan. Consensus around tables.
    • OpenSky says that since this didn't get into this trimester's Plan Of Record, they don't want to do it.
    • We've been resisting that opinion, and the issue is easy to address. Should be easy. Built into MySQL.
    • Sweet spot after proposal deadline; that would be a good time to implement this.
    • ** Brian to pursue this with OpenSky, CC Nicole and Stephan.
    • ** Stephan to do a one-time dump to a local database.
    • ** Nicole to create UserDatabasePlanOfRecordT12010
  6. XML Issue: GlobalID should be included in Author information?
    • Stub accounts can't have a GlobalID. (but we won't want author information then?)
    • non-stub accounts should have something like this; new schema will have these (optional).
    • What about timing?
    • Need to ratify this, approve it, before pushing towards OpenSky.
    • There should be an overlap where both servlets exist (old, new).
    • Resources section has separate subsections for EVLA and GB, totally independent.
    • Karen: currently getting upload to Carl's database. Longer term, GB has to replace proposal handling s/w; can't start review process for months:
      • Stephan: EVLA has tools that automatically convert XML to java objects. Can't do that right now with what they're sending (which is only syntactically (?) correct). Can finesse the difference (old/new) with a flag.
      • Realistically, a single NRAO-wide proposal handling (wrangling?) tool that works for GB is at least 1-2 years away.
        • Would need formal agreement on requirements, functionality, features, API, etc.
      • Consensus that EVLA can move on as planned, as long as GB isn't impacted (and it shouldn't be).
    • Side issue: won't be using ALMA proposal tool at this point; has too many additional constraints due to international nature of ALMA.
      • We (who?) should examine carefully what they have, to see if we can cherry-pick.
      • Tim Bastian has a working group (2 meetings so far) on NRAO-wide Proposal handling. Finding resources to determine requirements.

-- PatrickMurphy - 2009-12-17
Topic revision: r1 - 2009-12-17, PatrickMurphy
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback