Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
Hi all, I thank you for answering my queries. I understand the licensing issues behind GPLv3 from Sencha Ext JS. The other libraries provide the following licenses : 1. Dojo Toolkit : MIT License 2. JxLib : MIT License 3. UIZE : BSD License 4. MochaUI : MIT License I would like the community to help me in finalizing the suitable library for use in the project. Though some of these libraries make for a small learning curve, it would be a great opportunity for me to learn another javascript framework. Just as the XMLUI is based on Cocoon, webmvc is based on Spring WebMVC and DSpace REST is based on EntityBus, I would like the ClientUI to be based on a generic UI framework for consuming RESTful services. This would be an independent project hosted at http://github.com/tr4n2uil/entitybrowser Extensions to the EntityBrowser would be designed in the course of the GSoC project to provide support for each of the functional requirements [Repository Browsing and Manipulation / Search / Statistics]. In this way changes to REST API in view of its possible migration to Spring REST from EntityBus would have little changes to the ClientUI. I have already started work on EntityBrowser in Ext JS (though not committed yet) but I would be happy to port it to other javascript frameworks as per the decision of the community regarding the licensing issue. And as mentioned by Graham Triggs, the ClientUI will be a part of the DSpace (though currently as an independent module). Hence I would request Peter Dietz to create a new repository in DSpace (Git or SVN) for dspace-clientui module and provide me access since I have not yet obtained access to any repository. Warm regards, -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
Hi Vibhaj, I made: https://github.com/DSpace/restclient Its forked from the repository you mentioned for your extJS code. You can continue committing to your entitybrowser repository as usual, so you won't be slowed down. When you've got improvements, you can then either contact the mentor of your project, or send a pull request to DSpace/restclient to have your changes merged in. Having someone review the code before merging it is a way for us to have someone review your code. I named it restclient because that is more meaningful than than just clientUI. If you don't want it to be forked from the extJS project, or if it really should be named dspace-clientui, then please let me know, since its very easy to change. Peter Dietz On Fri, May 20, 2011 at 2:52 AM, Vibhaj Rajan vibhaj.rajan.cs...@itbhu.ac.in wrote: Hi all, I thank you for answering my queries. I understand the licensing issues behind GPLv3 from Sencha Ext JS. The other libraries provide the following licenses : 1. Dojo Toolkit : MIT License 2. JxLib : MIT License 3. UIZE : BSD License 4. MochaUI : MIT License I would like the community to help me in finalizing the suitable library for use in the project. Though some of these libraries make for a small learning curve, it would be a great opportunity for me to learn another javascript framework. Just as the XMLUI is based on Cocoon, webmvc is based on Spring WebMVC and DSpace REST is based on EntityBus, I would like the ClientUI to be based on a generic UI framework for consuming RESTful services. This would be an independent project hosted at http://github.com/tr4n2uil/entitybrowser Extensions to the EntityBrowser would be designed in the course of the GSoC project to provide support for each of the functional requirements [Repository Browsing and Manipulation / Search / Statistics]. In this way changes to REST API in view of its possible migration to Spring REST from EntityBus would have little changes to the ClientUI. I have already started work on EntityBrowser in Ext JS (though not committed yet) but I would be happy to port it to other javascript frameworks as per the decision of the community regarding the licensing issue. And as mentioned by Graham Triggs, the ClientUI will be a part of the DSpace (though currently as an independent module). Hence I would request Peter Dietz to create a new repository in DSpace (Git or SVN) for dspace-clientui module and provide me access since I have not yet obtained access to any repository. Warm regards, -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
Hi Peter, Thank you for creating the repository. The name restclient if fine. I would like to suggest that restclient repository be a new empty one and not a fork from entitybrowser since entitybrowser is a different project from restclient. I mean that I would be using entitybrowser as a framework to build the DSpace RestClient. Just provide me with an empty repository for RestClient work which I'll fork and use the entitybrowser framework there. I feel this would be cleaner. Thank you very much for the support. Warm regards, On Fri, May 20, 2011 at 9:47 PM, Peter Dietz pdiet...@gmail.com wrote: Hi Vibhaj, I made: https://github.com/DSpace/restclient Its forked from the repository you mentioned for your extJS code. You can continue committing to your entitybrowser repository as usual, so you won't be slowed down. When you've got improvements, you can then either contact the mentor of your project, or send a pull request to DSpace/restclient to have your changes merged in. Having someone review the code before merging it is a way for us to have someone review your code. I named it restclient because that is more meaningful than than just clientUI. If you don't want it to be forked from the extJS project, or if it really should be named dspace-clientui, then please let me know, since its very easy to change. Peter Dietz On Fri, May 20, 2011 at 2:52 AM, Vibhaj Rajan vibhaj.rajan.cs...@itbhu.ac.in wrote: Hi all, I thank you for answering my queries. I understand the licensing issues behind GPLv3 from Sencha Ext JS. The other libraries provide the following licenses : 1. Dojo Toolkit : MIT License 2. JxLib : MIT License 3. UIZE : BSD License 4. MochaUI : MIT License I would like the community to help me in finalizing the suitable library for use in the project. Though some of these libraries make for a small learning curve, it would be a great opportunity for me to learn another javascript framework. Just as the XMLUI is based on Cocoon, webmvc is based on Spring WebMVC and DSpace REST is based on EntityBus, I would like the ClientUI to be based on a generic UI framework for consuming RESTful services. This would be an independent project hosted at http://github.com/tr4n2uil/entitybrowser Extensions to the EntityBrowser would be designed in the course of the GSoC project to provide support for each of the functional requirements [Repository Browsing and Manipulation / Search / Statistics]. In this way changes to REST API in view of its possible migration to Spring REST from EntityBus would have little changes to the ClientUI. I have already started work on EntityBrowser in Ext JS (though not committed yet) but I would be happy to port it to other javascript frameworks as per the decision of the community regarding the licensing issue. And as mentioned by Graham Triggs, the ClientUI will be a part of the DSpace (though currently as an independent module). Hence I would request Peter Dietz to create a new repository in DSpace (Git or SVN) for dspace-clientui module and provide me access since I have not yet obtained access to any repository. Warm regards, -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
To be honest, we don't really need to be creating repositories in DSpace for this. You could just create an empty public repo under your own name - fork it from any existing repository that you need to, you can get people to collaborate on it and/or fork from it. And we can have the repo moved to the DSpace account at some point in the future when it is deemed appropriate. Regards, G On 20 May 2011 18:35, Vibhaj Rajan vibhaj.rajan.cs...@itbhu.ac.in wrote: Hi Peter, Thank you for creating the repository. The name restclient if fine. I would like to suggest that restclient repository be a new empty one and not a fork from entitybrowser since entitybrowser is a different project from restclient. I mean that I would be using entitybrowser as a framework to build the DSpace RestClient. Just provide me with an empty repository for RestClient work which I'll fork and use the entitybrowser framework there. I feel this would be cleaner. Thank you very much for the support. Warm regards, On Fri, May 20, 2011 at 9:47 PM, Peter Dietz pdiet...@gmail.com wrote: Hi Vibhaj, I made: https://github.com/DSpace/restclient Its forked from the repository you mentioned for your extJS code. You can continue committing to your entitybrowser repository as usual, so you won't be slowed down. When you've got improvements, you can then either contact the mentor of your project, or send a pull request to DSpace/restclient to have your changes merged in. Having someone review the code before merging it is a way for us to have someone review your code. I named it restclient because that is more meaningful than than just clientUI. If you don't want it to be forked from the extJS project, or if it really should be named dspace-clientui, then please let me know, since its very easy to change. Peter Dietz On Fri, May 20, 2011 at 2:52 AM, Vibhaj Rajan vibhaj.rajan.cs...@itbhu.ac.in wrote: Hi all, I thank you for answering my queries. I understand the licensing issues behind GPLv3 from Sencha Ext JS. The other libraries provide the following licenses : 1. Dojo Toolkit : MIT License 2. JxLib : MIT License 3. UIZE : BSD License 4. MochaUI : MIT License I would like the community to help me in finalizing the suitable library for use in the project. Though some of these libraries make for a small learning curve, it would be a great opportunity for me to learn another javascript framework. Just as the XMLUI is based on Cocoon, webmvc is based on Spring WebMVC and DSpace REST is based on EntityBus, I would like the ClientUI to be based on a generic UI framework for consuming RESTful services. This would be an independent project hosted at http://github.com/tr4n2uil/entitybrowser Extensions to the EntityBrowser would be designed in the course of the GSoC project to provide support for each of the functional requirements [Repository Browsing and Manipulation / Search / Statistics]. In this way changes to REST API in view of its possible migration to Spring REST from EntityBus would have little changes to the ClientUI. I have already started work on EntityBrowser in Ext JS (though not committed yet) but I would be happy to port it to other javascript frameworks as per the decision of the community regarding the licensing issue. And as mentioned by Graham Triggs, the ClientUI will be a part of the DSpace (though currently as an independent module). Hence I would request Peter Dietz to create a new repository in DSpace (Git or SVN) for dspace-clientui module and provide me access since I have not yet obtained access to any repository. Warm regards, -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
Hi Graham, Thanks for the suggestion. I'll do as you said. Warm regards, On Fri, May 20, 2011 at 11:46 PM, Graham Triggs grahamtri...@gmail.comwrote: To be honest, we don't really need to be creating repositories in DSpace for this. You could just create an empty public repo under your own name - fork it from any existing repository that you need to, you can get people to collaborate on it and/or fork from it. And we can have the repo moved to the DSpace account at some point in the future when it is deemed appropriate. Regards, G On 20 May 2011 18:35, Vibhaj Rajan vibhaj.rajan.cs...@itbhu.ac.in wrote: Hi Peter, Thank you for creating the repository. The name restclient if fine. I would like to suggest that restclient repository be a new empty one and not a fork from entitybrowser since entitybrowser is a different project from restclient. I mean that I would be using entitybrowser as a framework to build the DSpace RestClient. Just provide me with an empty repository for RestClient work which I'll fork and use the entitybrowser framework there. I feel this would be cleaner. Thank you very much for the support. Warm regards, On Fri, May 20, 2011 at 9:47 PM, Peter Dietz pdiet...@gmail.com wrote: Hi Vibhaj, I made: https://github.com/DSpace/restclient Its forked from the repository you mentioned for your extJS code. You can continue committing to your entitybrowser repository as usual, so you won't be slowed down. When you've got improvements, you can then either contact the mentor of your project, or send a pull request to DSpace/restclient to have your changes merged in. Having someone review the code before merging it is a way for us to have someone review your code. I named it restclient because that is more meaningful than than just clientUI. If you don't want it to be forked from the extJS project, or if it really should be named dspace-clientui, then please let me know, since its very easy to change. Peter Dietz On Fri, May 20, 2011 at 2:52 AM, Vibhaj Rajan vibhaj.rajan.cs...@itbhu.ac.in wrote: Hi all, I thank you for answering my queries. I understand the licensing issues behind GPLv3 from Sencha Ext JS. The other libraries provide the following licenses : 1. Dojo Toolkit : MIT License 2. JxLib : MIT License 3. UIZE : BSD License 4. MochaUI : MIT License I would like the community to help me in finalizing the suitable library for use in the project. Though some of these libraries make for a small learning curve, it would be a great opportunity for me to learn another javascript framework. Just as the XMLUI is based on Cocoon, webmvc is based on Spring WebMVC and DSpace REST is based on EntityBus, I would like the ClientUI to be based on a generic UI framework for consuming RESTful services. This would be an independent project hosted at http://github.com/tr4n2uil/entitybrowser Extensions to the EntityBrowser would be designed in the course of the GSoC project to provide support for each of the functional requirements [Repository Browsing and Manipulation / Search / Statistics]. In this way changes to REST API in view of its possible migration to Spring REST from EntityBus would have little changes to the ClientUI. I have already started work on EntityBrowser in Ext JS (though not committed yet) but I would be happy to port it to other javascript frameworks as per the decision of the community regarding the licensing issue. And as mentioned by Graham Triggs, the ClientUI will be a part of the DSpace (though currently as an independent module). Hence I would request Peter Dietz to create a new repository in DSpace (Git or SVN) for dspace-clientui module and provide me access since I have not yet obtained access to any repository. Warm regards, -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
On Sun, May 15, 2011 at 11:38 AM, Vibhaj Rajan vibhaj.rajan.cs...@itbhu.ac.in wrote: Hi Bojan Mark and Hello All, Regarding the GSoC project *New UI built over RESTful services*, I have referred the REST API [1] and the DSpace Manual for functional overview. I have also gone through the customizations available in JSPUI/XMLUI and the objectives of WebMVC FreeMarker UI [2]. The current implementation of DSpace REST module supports the following services : 1. Respository Browsing - Communities - Collections - Items - Bitstreams - Groups - Users 2. Repository Manipulation - Communities - Collections - Items 3. Content Searching - Search - Harvest 4. Statistics 5. Relationships [Experimental] Bojan, can we confirm if 1-3 will be sufficient in the face of improving the REST webapp to use Spring REST instead of EntityBroker? This gives me a broad idea regarding what services the UI shall be supporting. With reference to the customization support available in JSPUI/XMLUI, the following requirements are assumed to be realized within this scope : 1. Core Aspects - Artifact Browser - E-Person - Administrative - Statistics 2. Stylesheets (CSS) 3. Layout 4. Themes 5. Internationalization webmvc folks, this is where I think you might be of assistance, looking at these REST API parts 1-3 above (see https://wiki.duraspace.org/display/DSPACE/REST+API) and the proposal around a Javascript Based User interaction. Can you comment on if/where you feel that there is overlap with the Spring Controllers/Actions your creating in the webmvc project, specifically, we want to consider if we are talking about the same Controllers in both the REST and WebMVC cases and if the only difference between may actually just be the final View that is rendered (html, xml, json)? According to the proposal, the UI was planned to be developed using Ext JS. Though Ext JS remains my first choice, I have searched for JavaScript UI Frameworks and Toolkits on the web and these are the results in order of my preference : 1. Ext JS [3] 2. Dojo Toolkit [4] 3. JxLib [5] 4. UIZE [6] 5. MochaUI [7] I have less knowledge of licensing issues but all the above libraries have an open source distribution. Senchas interpretation of GPL is bordering on the ridiculous: http://www.sencha.com/legal/open-source-faq/ Example For example: let’s take a mortgage processing software program. Let’s say that the application has a front-end (that generates web pages linked to Ext JS JavaScript) that communicates over JSON/HTTP with a backend service. This backend service contains approval and validation logic for this application alone. Even if only the front-end uses Ext JS code, you should consider that the combination of front and back ends constitutes the application, and the source code for both back and front end would need to be provided to the application’s end users under GPLv3 if the application is used by an end-user who is not part of the same legal entity that holds the GPLv3 license to the Ext JS code. Sorry but THATS a BUNCH of BULL! So now GPL infects across http messaging protocol as well? Simply referencing a GPL javascript file via URL constitutes your application being a derivative work and having to be GPL'd as well? The problem with the above logic is that the Serverside Application is upstream, Ext JS is talking to it not the other way around, the server side application is not dependent on Ext JS, the Browser is the one thats dependent on ExtJS to render the view, so what then... all Browsers need to be GPL'd as well? I would buy that the javascript you write thats dependent on the ExtJS javascript would need to be GPL... but not the server delivering the REST interface it communicates with. The direction of dependency is important here... We will need to have a dialog about Javascript framework choices that are fitting for DSpace's BSD style licensing and determine if we tolerate using a library from a company with such an odd interpretation. I would heartily welcome suggestions/recommendations for the project from the community. [1] https://wiki.duraspace.org/display/DSPACE/REST+API [2] https://wiki.duraspace.org/display/DSPACE/WebMVC+(Freemarker)+UIhttps://wiki.duraspace.org/display/DSPACE/WebMVC+%28Freemarker%29+UI [3] http://www.sencha.com/products/extjs/ [4] http://dojotoolkit.org/widgets [5] http://jxlib.org/ [6] http://www.uize.com/ [7] http://mochaui.org/ Thanks and Regards, -- *Vibhaj Rajan Junior Undergraduate Department of Computer Engineering Institute of Technology BHU Varanasi +91 92 3531 2784 * -- Mark R. Diggory @mire - www.atmire.com 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010 Technologielaan 9 - 3001 Heverlee - Belgium
Re: [Dspace-devel] [duraspace-gsoc] Regarding GSoC Project : New UI built over RESTful services
On 19 May 2011 20:57, Mark Diggory mdigg...@atmire.com wrote: webmvc folks, this is where I think you might be of assistance, looking at these REST API parts 1-3 above (see https://wiki.duraspace.org/display/DSPACE/REST+API) and the proposal around a Javascript Based User interaction. Can you comment on if/where you feel that there is overlap with the Spring Controllers/Actions your creating in the webmvc project, specifically, we want to consider if we are talking about the same Controllers in both the REST and WebMVC cases and if the only difference between may actually just be the final View that is rendered (html, xml, json)? I would like to cool this talk a little bit. From my point of view, I have a clear vision and requirement as to what webmvc has to deliver, and in general I think it's better - particularly at this stage - for these projects to be driven by their visions, and we can refactor the common elements later (whatever happens, we'll need to refactor to fit all of these jigsaw pieces into whatever we support as 'core' DSpace going forward). Besides, these projects are likely working at a different level - in mvc, the controllers have a clearer mapping to pages, whereas here the controller are more functional based, with multiple calls being used in any one page. Although I'm very happy to trade experiences of using Spring [mvc]. Sorry but THATS a BUNCH of BULL! So now GPL infects across http messaging protocol as well? Simply referencing a GPL javascript file via URL constitutes your application being a derivative work and having to be GPL'd as well? The problem with the above logic is that the Serverside Application is upstream, Ext JS is talking to it not the other way around, the server side application is not dependent on Ext JS, the Browser is the one thats dependent on ExtJS to render the view, so what then... all Browsers need to be GPL'd as well? I would buy that the javascript you write thats dependent on the ExtJS javascript would need to be GPL... but not the server delivering the REST interface it communicates with. The direction of dependency is important here... We will need to have a dialog about Javascript framework choices that are fitting for DSpace's BSD style licensing and determine if we tolerate using a library from a company with such an odd interpretation. That sounds akin to someone using a GPL licensed browser - if anyone does, then any website that they access would have to adhere to the GPL, which is crazy. However, there is a more practical concern. You can't simply afford to reference a javascript file on some random server, and certainly not something as crucial as Ext JS. So, you need to package it with your application on your server - even if you separate the applications that form the front-end JS/html/css from the REST components, you have potential claims about the bits that are packaged together. Plus, we then have to consider the redistribution aspect. So yes, anything that is more clearly compatible with the BSD licensing would be preferable. G -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
