Hi all, I will comment a few points as I am not able to attend the summit.
--- 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. --- I think this is a good idea. In some cases Twitter has multiple APIs for the reason of different underlying architecture and techical implementations. The other reason could be an iterative evolution of their services and infrastructure. In the case of DSpace - maybe this point could be considered from the functional point of view. Generally, all the REST API versions would depend on the same DSpace-API, so the rationale for separation could be based on some other asumption. For instance, user-centric (browse), admin-centric (update) or similar, and/or based on the development effort or resources necessary to carry out the change. The example for the latter may be an outstanding decision about future development which may hold development/release of the component or part which is already clear and non-disputable. --- Mobile Device Support - DSpace is lagging behind. How do we plan to move in this direction? --- One approach in this direction could be based on [1] idea. Atomization and usage of lightweight components/architecture could lead to easier and less resource intensive development, maintenance and customization of ui. Also usage of cross-platform tools such as jQueryMobile, phoneGap or similar (+ REST API) could provide better coverage and require a less effort. [1] https://wiki.duraspace.org/display/GSOC/DSpace+ClientUI+built+on+RESTful+API+-+GSoC+2011 Regards, Bojan > 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 ------------------------------------------------------------------------------ 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
