On Thu, Sep 19, 2013 at 3:23 PM, Anja Le Blanc <anja.lebl...@manchester.ac.uk> wrote: > What are the consequences for future developments of one of these API's > getting into 'core' DSpace now?
Hi Anja, as you know, people have a lot of use cases that could be addressed by a REST API and the need for it has only grown in time. Therefore the commiters group wants to give users _something_ official to play with that can be supported and developed. With the 4.0 release imminent and no official pull requests filed, we've reconsidered all the alternatives. We agree that: * it's beneficial for the DSpace community if we commit to an official API * we would like to to include something usable even if it's not feature-complete * even if the underlying implementation would change or even be completely rewritten * because of the possibility of change, we're considering having the API versioned In addition to that, we finally formulated a set of minimal requirements for making an API official (we probably should have done that much sooner, sorry!). So, to answer your question, the consequence would be a wider exposure of the chosen API to DSpace users (thanks to lowering the barrier of entry and the official status). Hopefully, getting more users will result in discovering its deficiencies and getting improvements. > If a new API would come along - in a year or so - does it need to be > compatible with the one getting into DSpace now? Or should all > developments in future be done one the one API? Ideally, the chosen API would change as little as possible. However, the underlying implementation can change as needed at any time. Should it turn out that the API itself would benefit from changes, we might release a new version available as a separate URL endpoint. This is still open for discussion. In any case, the goal here is to give it a wide exposure and we're expecting that will help identify weak points, so for 4.0, we'd slap some sort of beta label on it. > We are using both Wijiti and Hedtek and are not completely happy with > either. For once run a GET on all items on a repository with enough > content and your Tomcat can easily run out of memory and die. Not very > suitable for a service environment. You're one of the few users who worked with both and are able to judge which one is better. What we currently care about the most is which API is the best to work with, not which implementation. If the problem you mentioned is inherent to the API design, the API design should change (e.g. adopt resumption tokens like in OAI-PMH). Even if you think that all the available APIs are way too cumbersome to use and we'd be better off waiting for another year for a design from scratch, we'd still like to hear your opinion. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette ------------------------------------------------------------------------------ LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
