...
- Time: 12:00pm Eastern Daylight Time US (UTC-4)
- Place: Google-hangout, https://plus.google.com/hangouts/_/event/c1glu6soq43r1rr6ou17qtobug8
Attendees
Andrew Woods- Esme CowlesBenjamin Armintor
- Daniel Davis
- Declan Fleming
- A. Soroka
- Benjamin Armintor
- Zhiwu Xie
- Yinlin ChenUnknown User (escowles@ucsd.edu)
Agenda
- Review assessment progress
- REST API specification
- Performance
- Preservation-worthiness
- Clustering
- Discussion: removing functionality not ready for production
Discussion
Assessment:
- Preservation: Esme: ingest working, scaling up -- filed a bug for performance of meadata updates on a federated filesystem which is being worked this sprint.
- REST API: Ben: no update other than LDP paging discussions, but still hopeful of wrapping this up this month.
- Performance: Dan: populating scenarios, with variations on ingest/access, concurrency, different file sizes, etc. Will work with Kevin Clarke, who is working on Grinder this sprint.
Functionality Discussion:
- Chris: Doing LDP alignment work and touching a lot of code, found several "soft spots" where code isn't ready for 4.0 release.
- Features proposed for removal from 4.0 release:
- Batch API: good idea for possible performance improvement, but not being used by anyone yet.
- Field Search: promising feature, could be used instead of external search engine
- Ben: inclined to view SPARQL as better defined, better match to LDP
- Chris: there are SPARQL fulltext extensions (e.g. https://jena.apache.org/documentation/larq/), but not ready for 4.0 either.
- ID Minting: REST API support for minting identifiers was mostly added for F3 parity, really a separate concern from the repository
- Ben: more interested in having small and well-defined API going forward than replicating F3 functionality
- Esme: having pluggable auto-generated ids is the important feature
- Repository-wide SPARQL updates (fcr:properties): PATCH support makes this redundant
- Namespace management (fcr:namespaces): there is a need for namespace management, but this implementation isn't necessarily the right approach
- Sitemaps:
- Chris: important, but implementation is flawed, should be part of ResourceSync discussions
- Ben: we need to support sync, but not a special API
- Workspaces: good idea, with some use cases, but not working well
- Ben: another JCR feature, multi-tennancy desired by vendors
- Esme: Need to get engagement on this, refocus on use case instead of JCR functionality
- Audit:
- Dan: another case where use case is important, and needed for authenticity -- need central audit log, with object view
- Chris: implementation doesn't satisfy use case, not heavily used for 3.x
- Dan: needs to be on roadmap, will be increasingly important for 3.x migrations
- DC Generator: could be part of OAI-PMH functionality, not required for 4.0
- Policy-driven storage: Esme: could be more relevant now that Jersey 2 upgrade allows better async support
- Features in need of attention:
- Versioning: used by Penn State (migrating versions from F3)
- Current options are confusing
- May want to revise model for 4.1
- Ben: Memento could be a good fit
- Transactions: interactions of transactions with other features, which aren't transaction-aware
- Chris: Session / Transaction interactions in particular are hacky
- Ben: maybe Jersey 2 cleanup could help this
- JAX-RS cleanup: Ben: there were session injection things that didn't work before that we can revisit now
- RDF: need real-world testing of different formats (Penn State: ntriples, UCSD: rdf/xml, need n3/ttl testing)
- Versioning: used by Penn State (migrating versions from F3)
Actions
Excerpt |
---|
|