Hello Tim, Aaron and others, I will first answer the questions:
> (1) We noticed that the REST API documentation on the wiki currently > doesn't mention anything about Authentication. How is > authentication expected to be handled (or being handled)? Is it > just Basic HTTP Auth? Is there any extra configuration/setup that > should be documented on the wiki page? It might be good to document > how authentication is expected to be handled, and anything else > worth knowing in this area. Yes you are right, it is not mentioned there. Currently the authentication is done simply by providing the user name and password as request parameters (e.g. GET /rest/items/1.json?user=xxx&pass=xxx). If there is a a need within community for other mechanism I will gladly extend the code to support it. Also regarding comments on the wiki, I have took them into account and so it should be ok. > (2) We also noticed there isn't mention of Authorization in the wiki > documentation. From looking at the code, it looks like you are > handling Authorization by letting the dspace-api handle it (which is > perfectly fine, in my opinion). You then catch any > AuthorizationExceptions thrown and return a 401 or 403 response, > depending on the situation. (Please correct me if I'm wrong about > anything I've stated.) It just might be good to also document that > more clearly, so that everyone is aware how Authorization is being > handled and what happens when you are not authorized to make a > change or access a particular resource. Yes, that it correct, the authorization is forwarded to the underlying structures itself and the errors are catched and returned to the user. In the most cases the application provides an message about failure to process a request - in the case of unsuccessful Authorization or any other case. Ofcourse, the code returns descriptions of the errors in the form provided by the underlying libraries. This means, if related components do not return exact description, nor the rest api can. > (3) Finally, we were all just curious how "ready" both you and Aaron > feel this code is. Do you both feel the REST API will be ready for > at least a "beta" level release after GSoC (i.e. do you feel it > should be considered for public release in DSpace 1.7)? Or are > there more outstanding issues/concerns that you each feel need > resolution (and if so, what are they)? The developers are > interested in hearing your thoughts on the work, and whether there > are outstanding issues/concerns you may have in making this work > more broadly available. (Bojan, any concerns/issues you mention > will not hurt your GSoC final grade. We are just looking to better > understand to current status of the code, and whether there is still > more that needs working on before it is "ready for release") Ok, I will comment this from my perspective. First, the wiki is not currently following the status of the software development. As I have been working on the particular aspects of the code, updating the wiki after each change would produce unnecessary context switching and overhead, thus causing inefficient use of the time resources available. Instead the wiki (in this phase) has been used mostly for a draft proposal how all should look like e.g. the organization of the endpoints, functions covered, the handling/manipulation of resources and so. Now that some questions were raised, I will update the wiki with the information requested and will also change it to better resemble current status of the project. E.g. some methods have been changed, especially related to creation of new resources (update/getting hasn't been changed much). For the issues/concerns, this time I have been focused more on the following aspects: - decoupling parts of the code and moving the direct handling routines (like accessing the resources directly) from entity providers' level to entities; this should make easier support among different versions of DSpace and make easier transition to new storage api - taking into account the user need to manipulate with the resources, e.g. create new communities, update/create items and so From this point, one issue may be the fact that implementation of all dspace-api -> dspace-rest mappings and support for all those functions could require too much effort and time, while many of those functions would not be used by most of the users. Instead in this wiki I have drafted/proposed the functions (endpoints/features) which would have the highest priority to implement and thus represent this first official REST support for the DSpace. For this first (version) I think it is ok, and then we may see user/developer feedback and implement other functions. Also from the last year's project I already got some feedback so it was good starting point for me. Other issue for me was the introduction of other new projects, e.g. Backporting of DSpace 2 Storage Services and Semantic Content Repository. Current version of the code uses DSpace1 approach and libraries and once other implementations are ready we can think making this code dependent/related to them. For the software stability etc, I must admit that I haven't had much time to test functionality/correctness of the output results. While I tested each feature manually during the implementation, I suppose there will be many small bugs to correct. One repository of say 100 or so items could be good starting point for testing. It would be good if someone could help me to get such repository, then I could write automatic tests (or use other testing methodology) and this way many of those small bugs could be found prior to release. And generally for the testing of the software I think also that community should decide up to which extent we should test the code before going into official release. As October 22rd is the freezing point, can 5-6 weeks be enough for us all to check the code and correct the errors found? Other issue, timeline, I think not everything will be finished up to the official end of GSoC. However I will also continue to work on it after GSoC end and I expect it would require a few weeks more before it could go to the testing. I would say maybe 2-3 weeks or before mid-September. This would give some 6 weeks for testing and fixing. What do you think, is it enough time for inclusion? I would like this package to be finished and ready for 1.7 release so will try to invest reasonable effort from my side in order to make it so. Also as I said before I plan to support this code after (possible) inclusion in the release so if this produced some concerns or reserves I just wanted to let you know it. Regards Bojan
------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
