Page History
...
We took notes via IRC. So, the full notes are up in IRC chatroom: http://irclogs.duraspace.org/index.php?date=2012-02-27
Day #2 Notes (Feb 28)
Attendees: Kevin Van De Velde, Mark Wood, Andrea Schweer, Richard Rodgers, Scott Phillips, Mark Diggory, Hardy Pottinger, Peter Dietz, Tim Donohue
Primary Discussion topics:
- Revisiting REST API Discussion
- Seems to be an assumption that we should only have one REST API
- No reason why we cannot have multiple APIs, or even different implementations (and let the best one win out in the end)
- Revisiting whether one REST API should 'wrap' all calls. Tim noticed Twitter (and many other sites have many many REST APIs)
- https://dev.twitter.com/docs
- Twitter specifically has a basic REST API, Search API, Streaming API, etc. They even do OAuth / AuthZ via REST API.
- https://dev.twitter.com/docs
- Business Logic API
- Can we "mature" design/modeling of the Business Logic API by thinking of it more as a REST API?
- Services that would be part of a Business Logic API:
- Item Submission processes (special ingest workflow)
- Reviewer Workflow processes
- Creation processes for Collections / Communities (also includes initializing roles, template items, etc. – almost like a "workflow" process to create these objects)
- Creation processes for Groups / EPeople?
- Running Curation Tasks - Richard Rodgers notes he's already building a demo REST API for Curation Framework using Jersey (http://jersey.java.net/
). This will be posted to GitHub in near future
- Smaller Activities: User feedback, Statistics, metadata registry, bitstream format registry
- Authority Control? (managing internal or external controlled vocabularies & taxonomies)
- Questions / Concerns on Business Logic API
- Need to avoid it being too "large" / all-encompassing.
- Where do we draw the line between underlying "DSpace Business Logic" and UI? E.g. Is Search/Browse part of Business Logic API? Or is it a separate API?
- Mentioned that DSpace Discovery Module has been made more generic (no longer Solr specific) – may be the basis for a separate "Search API"?
- REST API usage of Sakai bus
- Are we satisfied with the Sakai-based REST implementation? Sounds like several have concerns about complexity & ongoing maintanence
- May need to work towards a new implementation – based on Spring WebMVC or something else (Apache CXF? Jersey?)
- Should be able to still reuse much of existing REST API work – especially the modeling of DSpace Objects as Resources bound to URLs
- Mobile Device Support - DSpace is lagging behind. How do we plan to move in this direction?
- Several seem interested in this, but no one known to be working directly on it.
- Two levels of mobile support: (1) Making current UIs more 'mobile friendly' , (2) making DSpace more RESTful to support building native apps/clients
We took notes & shared additional links via IRC. http://irclogs.duraspace.org/index.php?date=2012-02-28
Overview
Content Tools