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
