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
