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)+UI<https://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
------------------------------------------------------------------------------
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

Reply via email to