Notes for Standup 2013.20-Block.3.2 (5/12 to 5/25)
=================================================

Chris B.
--------
Robert
------
David Doyle
-----------
Roger Dahl
----------
Rob
---
Skye
----
Dave
----
Matt
----
Ben
---
Chris
-----
ONEDrive Discussion
-------------------
User Settings API notes
Talk with Skye on Indexing Plans
--------------------------------

topics:

1. (P1) Foresite for parsing resource maps - redmine 3723

- Chris B has this on his schedule after Ansible


2. Generalized pattern for index processing

- pluggable pre-processing
- SOLRField class supports this
- Issue is picking up the new code in a running process - simplest is to simply add and restart.


2. a. (P2) Performance of indexing - redmine 3766
- multiple instances of SOLR can work with the same index. e.g. search instance handling public requests, then start up one or more jetty instances that can write to the index.
    - Replace the hazelcast iterator with a postgres query.
    - Improve the commit strategy refresh/rebuild

3. (Depends somewhat on #4) Upgrade to SOLR 4 and related upgrades - subtask of redmine 3764

- Cloud design - write to a single virtual instance that is manifest across the CNs.
  - would significantly reduce the hazelcast traffic since sysmeta would only be pulled by one CN
- Would require rebuilding index, perhaps some schema redesign, some new required fields (e.g. version)
- Provides a new upgrade path for solr for dataONE.  Debian packaging. (perhaps start from https://github.com/zeraholladay/solr4-tomcat-debian )


4. (P3) Refactoring the solr index schema, especially for dealing with packages - redmine 3726

Need to denormalize data as much as possible - but tradeoff is flexibility. 

- Add support for data set variables (e.g. column name and units)

- http://siren.sindice.com/documentation.html (seems a bit dated)
- http://jena.apache.org/documentation/larq/



5. OpenSearch (parallel activity - lots of design required) - redmine 3608

- Issues with state management - query, page, etc.
- Scalability of view generation using SOLR as a velocity template engine
- Example templates were fairly broken
- Seems best to havea separate java app to implement the view rendering and perhaps handle some/most of hte state information