Hi Tim,
I think a good point was made on the Virtual Summit meeting notes, namely "No
reason why we cannot have multiple APIs, or even different implementations (and
let the best one win out in the end)".
As part of a previous project, we took that approach and created our own DSpace
API based on Groovy/Grails (Grails is essentially a Spring MVC app). We had a
number of reasons for doing this but primarily it was due to a requirement for
the API to work with DSpace v1.5.2.
The API is available in GitHub (https://github.com/edina-jorum/Jorum-API) for
anyone interested and documentation can be found at:
http://developer.edina.ac.uk/projects/jorumapi/wiki/V0p3_Methods
You will see that a very limited set of methods are supported but some of the
code may be useful to others. We also had a very limited timeframe and as such
some of the DSpace core API code was copied across - this obviously is not a
valid long term approach but could be refactored.
I have hopes to extend this API at some point to support a fuller function set
but we don't have any developers free at present.
Hope that helps
Gareth
On 28 Feb 2012, at 22:53, Tim Donohue wrote:
> Hi All,
>
> Just wanted to follow up on this thread from a while back about the
> question of using the "Sakai bus for the REST API". I think Bojan gave
> a great description of why this decision was made initially.
>
> However, it's worth mentioning that this topic came up in today's
> discussion at our "Virtual Summit" that the Committers are holding this
> week.
>
> It should be noted that several DSpace Committers also have some
> concerns about the ongoing maintenance of the Sakai bus implementation
> (more out of complexity and whether there will be any ongoing support
> via Sakai). So, there already have been some discussions around whether
> we start to re-implement parts via Spring WebMVC or another popular
> framework (Jersey, Apache CXF, etc.) [1]
>
> There was no consensus around which framework(s) to utilize going
> forward, or even whether anyone in particular was willing to start to
> move this idea forward. Rather, it was just a consensus that we should
> take a step back and determine whether it might be worthwhile to replace
> the Sakai implementation with something else.
>
> In any case, just thought those following this thread may be interested
> in that discussion. More notes up at:
>
> https://wiki.duraspace.org/display/DSPACE/DevMtg+2012-02-27+-+Virtual+Summit#DevMtg2012-02-27-VirtualSummit-Day%232Notes%28Feb28%29
>
> - Tim
>
>
> [1] Related links:
> * Spring WebMVC
> http://blog.springsource.org/2009/03/08/rest-in-spring-3-mvc/
> * Jersey: http://jersey.java.net/
> * Apache CXF: http://cxf.apache.org/
>
> On 2/7/2012 10:57 AM, Bojan Suzic wrote:
>> Hi Mark,
>>
>> Am 07.02.2012 17:36, schrieb Mark van Harmelen:
>>
>>> * Many exceptions are being caught and thrown away. We predict that in
>>> times of trouble this will make the API impossible to debug.
>>
>> Many of the exceptions are related to handling of access rights of
>> request sender and some other relate to resource availability. I am not
>> sure about this statement, what would be your suggestion?
>>
>>> * We suspect that the API may fail under conditions of heavy load.
>>> We'd like to know more about the choice of the Sakai bus for the API
>>> code, and how well that has been applied. The concern is that
>>> endpoint parameters (that are set when an endpoint is invoked) may
>>> be overwritten under heavy load, thereby causing the API to fail.
>>
>> Sakai bus has been chosen during initial interface design by the
>> developers, prior to the implementation. I suppose one of the reasons
>> was the fact that one of DSpace developers was Sakai developer too,
>> knowing both systems and requirements. Also, at the time of
>> consideration it provided the fastest and most flexible way for
>> implementation.
>>
>> Regarding your concern, I think that the setting of parameters is
>> request based, therefore, they shouldn't be overwritten (if that's
>> reason for concern).
>>
>> Regards
>> Bojan
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Dspace-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
--
Gareth Waller
EDINA
The University of Edinburgh
Causewayside House
160 Causewayside
Edinburgh
EH9 1PR
Email: [email protected]
Skype: edina_gwaller
EDINA: http://edina.ac.uk
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
