You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rather than continuing to roll our own search and visualization tool, we should consider adopting SolrWayback and collaborating with the NAS team on it. We could start by making it available as an internal tool, within the W3ACT stack. For this, we need to:
Dockerise it in a way that allows it to work to our Solr indexes.
Cope with content_type being either single or multiValued.
Ensure required configuration options to be overridden from environment variables.
Tomcat should log the response from the server when calls to Solr fail: add alternative logback config for Docker so logs go to the console not a file.
Implement HTTP and/or WebHDFS WARC record retrieval back-ends so it can work properly with our WARC store.
SolrWayback relies on url_norm for many queries, but our older indexes do not contain it. Can we work around this somehow?
To facilitate automated CI testing, switch to a test WARC as well as test Solr documents, i.e. use consistent records so we can search and replay from the test system.
Allow WAR name to be overridden on launch, so I can use act#solrwayback and hence get it to deploy in the right place.
Allow alternative playback engine to be overridden. Added ALT_PLAYBACK_PREFIX env var.
Also override regex for path as our Solr has name only not full path.
Now built as ukwa/solrwayback:docker-hub-action for testing. Should be configurable to talk to our Solr and WARC servers, and deployable as part of the W3ACT stack.
I have modified the fork of SolrWayback to use relative paths in Vue and it seems to work. Documentation indicates that this feature may not work with history.pushState. See the 'limitations' section of https://cli.vuejs.org/config/#publicpath
Rather than continuing to roll our own search and visualization tool, we should consider adopting SolrWayback and collaborating with the NAS team on it. We could start by making it available as an internal tool, within the W3ACT stack. For this, we need to:
content_type
being either single or multiValued.url_norm
for many queries, but our older indexes do not contain it. Can we work around this somehow?act#solrwayback
and hence get it to deploy in the right place.ALT_PLAYBACK_PREFIX
env var./act/solrwayback
).It's possible we can't resolve some of these issues without re-indexing. In which case, this will have to wait.
Notes on public use moved to #73
The text was updated successfully, but these errors were encountered: