[xwiki-devs] [GSoC 2011] Self Introduction and Interested Project
Hi, Everyone, I am going to apply for student developer in GSoC 2011 and am interested in one of proposed XWiki projects, XEclipse "RESTification". Currently I am a fourth year Ph.D. student in the department of Computer Science, University of Georgia, USA. My research focuses on Simulation/Modelling and Web services, and applies them to facilitate bioinformatics research. My strengths are the following: (1). 6-year of Java programming experience including both desktop and web development and able to perform full lifecyle software development. (2). developed a SOAP Web service management system using Eclipse RCP and SWT (3). developed REST-ful Web services and integrated SOAP Web services from other collaborators (in German and Japan) to implement integrated scientific workflow following Web 2.0 standards After reading through the descriptions of proposed projects, XEclipse "RESTification" is of great interest to me. This project involves communication via SOAP and REST-ful Web services and is developed in Eclipse SWT platform, therefore, I might be a potential match for this project based on the skill set. I have several questions regarding the requirement: (1) what is target development platform? The current XEclipse requires Eclipse Ganymede 3.4 and the most recent release is Eclipse 3.6 and 3.7. Is there any plan to support them? (2) What is the current status of XWiki communication layer? From what I understand, SOAP + XML play a main role in the current system. Now XWiki is turning to REST eventually. I read some discussions on Mar 11 2011 about REST API in dev mail list, which mentioned that REST API is not there yet. Does this mean that the whole REST communication layer is not available yet? (3) What extent of RESTification we are going to achieve for XEclipse? This is closely related to question (2). If REST API is available, the XEclipse RESTification will only need to construct the REST-ful request (i.e., @GET /rest/{space}/{page}) and parse result from server. If not, more work might be involved. Best regards Jun Han -- Jun Han Computer Science Department, the University of Georgia http://sites.google.com/site/junhan37/
Hi, On Wed, Mar 23, 2011 at 18:35, Jun Han <[email protected]> wrote:
Hi, Everyone,
I am going to apply for student developer in GSoC 2011 and am interested in one of proposed XWiki projects, XEclipse "RESTification".
Great you are interested in this project !
Currently I am a fourth year Ph.D. student in the department of Computer Science, University of Georgia, USA. My research focuses on Simulation/Modelling and Web services, and applies them to facilitate bioinformatics research.
My strengths are the following: (1). 6-year of Java programming experience including both desktop and web development and able to perform full lifecyle software development. (2). developed a SOAP Web service management system using Eclipse RCP and SWT (3). developed REST-ful Web services and integrated SOAP Web services from other collaborators (in German and Japan) to implement integrated scientific workflow following Web 2.0 standards
After reading through the descriptions of proposed projects, XEclipse "RESTification" is of great interest to me. This project involves communication via SOAP and REST-ful Web services and is developed in Eclipse SWT platform, therefore, I might be a potential match for this project based on the skill set.
I have several questions regarding the requirement: (1) what is target development platform? The current XEclipse requires Eclipse Ganymede 3.4 and the most recent release is Eclipse 3.6 and 3.7. Is there any plan to support them?
I would say the minimum target is the Eclipse version when you are done with the project so probably 3.7. I doubt we really have to take care of supported previous versions, at least continuing supporting 3.4 is not a requirement IMO.
(2) What is the current status of XWiki communication layer? From what I understand, SOAP + XML play a main role in the current system. Now XWiki is turning to REST eventually. I read some discussions on Mar 11 2011 about REST API in dev mail list, which mentioned that REST API is not there yet. Does this mean that the whole REST communication layer is not available yet?
The REST APi is already there and a lot more complete than the XMLRPC one. You can take a look at it on https://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rest/ and http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI.
(3) What extent of RESTification we are going to achieve for XEclipse? This is closely related to question (2). If REST API is available, the XEclipse RESTification will only need to construct the REST-ful request (i.e., @GET /rest/{space}/{page}) and parse result from server. If not, more work might be involved.
AFAIK the goal is to at least refactor all current features of XEclipse to use REST instead of XMLRPC and if you can find some missing API add them to the standard XWiki REST module.
Best regards Jun Han -- Jun Han Computer Science Department, the University of Georgia http://sites.google.com/site/junhan37/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi Jun On Wed, Mar 23, 2011 at 6:35 PM, Jun Han <[email protected]> wrote:
Hi, Everyone,
I am going to apply for student developer in GSoC 2011 and am interested in one of proposed XWiki projects, XEclipse "RESTification".
Glad to hear that you are interested in this project. Thomas has already replied to your questions but I will add some bits as one of the mentors of the project.
Currently I am a fourth year Ph.D. student in the department of Computer Science, University of Georgia, USA. My research focuses on Simulation/Modelling and Web services, and applies them to facilitate bioinformatics research.
My strengths are the following: (1). 6-year of Java programming experience including both desktop and web development and able to perform full lifecyle software development. (2). developed a SOAP Web service management system using Eclipse RCP and SWT
Very good.
(3). developed REST-ful Web services and integrated SOAP Web services from other collaborators (in German and Japan) to implement integrated scientific workflow following Web 2.0 standards
Very good.
After reading through the descriptions of proposed projects, XEclipse "RESTification" is of great interest to me. This project involves communication via SOAP and REST-ful Web services and is developed in Eclipse SWT platform, therefore, I might be a potential match for this project based on the skill set.
I have several questions regarding the requirement: (1) what is target development platform? The current XEclipse requires Eclipse Ganymede 3.4 and the most recent release is Eclipse 3.6 and 3.7. Is there any plan to support them?
The "requires Ganymede" is a leftover... When XEclipse was actively developed the most stable Eclipse version was 3.3 (hence the "require 3.4") I didn't try but I think that XEclipse should run without any problem on 3.7 right now. Anyway the idea is to support the latest version of Eclipse, i.e. 3.7
(2) What is the current status of XWiki communication layer? From what I understand, SOAP + XML play a main role in the current system. Now XWiki is turning to REST eventually. I read some discussions on Mar 11 2011 about REST API in dev mail list, which mentioned that REST API is not there yet. Does this mean that the whole REST communication layer is not available yet?
Not quite right. XWiki supports XMLRPC and REST. AFAIK, We don't have any "SOAPy" web services. I would say that XMLRPC is deprecated because it has several problems and limitations. So the RESTful API is definitely the preferred mechanism for interacting with XWiki in a "machine oriented" way. Thomas already told you where to find information about this API (code https://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rest/ and documentation http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI)
(3) What extent of RESTification we are going to achieve for XEclipse? This is closely related to question (2). If REST API is available, the XEclipse RESTification will only need to construct the REST-ful request (i.e., @GET /rest/{space}/{page}) and parse result from server. If not, more work might be involved.
Indeed whay you say is part of the job. However XEclipse has an "abstraction layer" for the communication. This abstraction layer provides interfaces for retrievening and manipulating XWiki objects. Now the main goals of the project is to provide an HTTP-based implementation of this layer so that XEclipse will be able to communicate to with XWiki using REST. This is of course the tip of the iceberg :) Actually while "RESTifying" this we should also refactor where necessary and improve things. For example, one thing that comes to my mind is to enable lazy retrieval everywhere: we don't want to load in the interface thousands of items using a single request! I hope that this answers your questions and if you have more don't hesitate to ask! Cheers, Fabio
Dear Thomas and Fabio, Thanks a lot for your prompt replies and they helped a lot to understand the project. When I took a first thought about how to achieve RESTification, one thing popped out of my head is to add an abstract communication layer to XEclipse without touching its logic and user interface implementation. Considering the fact that XEclipse itself will be under major code refactoring in the project of "XEclipse editors improvement" as well, adding an abstract layer will make the two projects work in parallel without too much conflict. From Fabio's email, this abstract communication layer is already available for XEclipse, but it is not RESTful yet. Therefore, I will take a deeper look at the source code of XEclipse with two questions in mind: 1. figure out a way to refactor without affecting the logic and UI layer of XEclipse 2. provide more support for logic layer, e.g., lazy initialization/retrieval Best regards Jun Han On 03/24/2011 06:33 AM, Fabio Mancinelli wrote:
Hi Jun
On Wed, Mar 23, 2011 at 6:35 PM, Jun Han<[email protected]> wrote:
Hi, Everyone,
I am going to apply for student developer in GSoC 2011 and am interested in one of proposed XWiki projects, XEclipse "RESTification".
Glad to hear that you are interested in this project. Thomas has already replied to your questions but I will add some bits as one of the mentors of the project.
Currently I am a fourth year Ph.D. student in the department of Computer Science, University of Georgia, USA. My research focuses on Simulation/Modelling and Web services, and applies them to facilitate bioinformatics research.
My strengths are the following: (1). 6-year of Java programming experience including both desktop and web development and able to perform full lifecyle software development. (2). developed a SOAP Web service management system using Eclipse RCP and SWT
Very good.
(3). developed REST-ful Web services and integrated SOAP Web services from other collaborators (in German and Japan) to implement integrated scientific workflow following Web 2.0 standards
Very good.
After reading through the descriptions of proposed projects, XEclipse "RESTification" is of great interest to me. This project involves communication via SOAP and REST-ful Web services and is developed in Eclipse SWT platform, therefore, I might be a potential match for this project based on the skill set.
I have several questions regarding the requirement: (1) what is target development platform? The current XEclipse requires Eclipse Ganymede 3.4 and the most recent release is Eclipse 3.6 and 3.7. Is there any plan to support them?
The "requires Ganymede" is a leftover... When XEclipse was actively developed the most stable Eclipse version was 3.3 (hence the "require 3.4") I didn't try but I think that XEclipse should run without any problem on 3.7 right now.
Anyway the idea is to support the latest version of Eclipse, i.e. 3.7
(2) What is the current status of XWiki communication layer? From what I understand, SOAP + XML play a main role in the current system. Now XWiki is turning to REST eventually. I read some discussions on Mar 11 2011 about REST API in dev mail list, which mentioned that REST API is not there yet. Does this mean that the whole REST communication layer is not available yet?
Not quite right.
XWiki supports XMLRPC and REST. AFAIK, We don't have any "SOAPy" web services. I would say that XMLRPC is deprecated because it has several problems and limitations.
So the RESTful API is definitely the preferred mechanism for interacting with XWiki in a "machine oriented" way.
Thomas already told you where to find information about this API (code https://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rest/ and documentation http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI)
(3) What extent of RESTification we are going to achieve for XEclipse? This is closely related to question (2). If REST API is available, the XEclipse RESTification will only need to construct the REST-ful request (i.e., @GET /rest/{space}/{page}) and parse result from server. If not, more work might be involved.
Indeed whay you say is part of the job. However XEclipse has an "abstraction layer" for the communication. This abstraction layer provides interfaces for retrievening and manipulating XWiki objects.
Now the main goals of the project is to provide an HTTP-based implementation of this layer so that XEclipse will be able to communicate to with XWiki using REST. This is of course the tip of the iceberg :)
Actually while "RESTifying" this we should also refactor where necessary and improve things. For example, one thing that comes to my mind is to enable lazy retrieval everywhere: we don't want to load in the interface thousands of items using a single request!
I hope that this answers your questions and if you have more don't hesitate to ask!
Cheers, Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, Glad to hear you're interested in XEclipse. On 03/24/2011 04:47 PM, Jun Han wrote:
Dear Thomas and Fabio,
Thanks a lot for your prompt replies and they helped a lot to understand the project.
When I took a first thought about how to achieve RESTification, one thing popped out of my head is to add an abstract communication layer to XEclipse without touching its logic and user interface implementation. Considering the fact that XEclipse itself will be under major code refactoring in the project of "XEclipse editors improvement" as well, adding an abstract layer will make the two projects work in parallel without too much conflict. Given the fact that the two projects don`t really affect one another, you are pretty much free to experiment.
Besides that, you will be working on a separate fork of the XEclipse project (most likely in the sandbox svn directory http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/ ) which you will merge back when you are finished.
From Fabio's email, this abstract communication layer is already available for XEclipse, Yes. You can find the interface and the two (local-Filesystem and remote-XML-RPC) implementations here http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.... but it is not RESTful yet. Therefore, I will take a deeper look at the source code of XEclipse with two questions in mind: 1. figure out a way to refactor without affecting the logic and UI layer of XEclipse You could start by providing an implementation equivalent to RemoteXWikiDataStorage.java but which uses REST instead of XML-RPC, then work your way up by extending the IDataStorage.java interface with new functionality and provide the equivalent UI. 2. provide more support for logic layer, e.g., lazy initialization/retrieval
Best regards Jun Han Feel free to ask if you have any more questions.
Good luck, Eduard
On 03/24/2011 06:33 AM, Fabio Mancinelli wrote:
Hi Jun
On Wed, Mar 23, 2011 at 6:35 PM, Jun Han<[email protected]> wrote:
Hi, Everyone,
I am going to apply for student developer in GSoC 2011 and am interested in one of proposed XWiki projects, XEclipse "RESTification".
Glad to hear that you are interested in this project. Thomas has already replied to your questions but I will add some bits as one of the mentors of the project.
Currently I am a fourth year Ph.D. student in the department of Computer Science, University of Georgia, USA. My research focuses on Simulation/Modelling and Web services, and applies them to facilitate bioinformatics research.
My strengths are the following: (1). 6-year of Java programming experience including both desktop and web development and able to perform full lifecyle software development. (2). developed a SOAP Web service management system using Eclipse RCP and SWT
Very good.
(3). developed REST-ful Web services and integrated SOAP Web services from other collaborators (in German and Japan) to implement integrated scientific workflow following Web 2.0 standards
Very good.
After reading through the descriptions of proposed projects, XEclipse "RESTification" is of great interest to me. This project involves communication via SOAP and REST-ful Web services and is developed in Eclipse SWT platform, therefore, I might be a potential match for this project based on the skill set.
I have several questions regarding the requirement: (1) what is target development platform? The current XEclipse requires Eclipse Ganymede 3.4 and the most recent release is Eclipse 3.6 and 3.7. Is there any plan to support them?
The "requires Ganymede" is a leftover... When XEclipse was actively developed the most stable Eclipse version was 3.3 (hence the "require 3.4") I didn't try but I think that XEclipse should run without any problem on 3.7 right now.
Anyway the idea is to support the latest version of Eclipse, i.e. 3.7
(2) What is the current status of XWiki communication layer? From what I understand, SOAP + XML play a main role in the current system. Now XWiki is turning to REST eventually. I read some discussions on Mar 11 2011 about REST API in dev mail list, which mentioned that REST API is not there yet. Does this mean that the whole REST communication layer is not available yet?
Not quite right.
XWiki supports XMLRPC and REST. AFAIK, We don't have any "SOAPy" web services. I would say that XMLRPC is deprecated because it has several problems and limitations.
So the RESTful API is definitely the preferred mechanism for interacting with XWiki in a "machine oriented" way.
Thomas already told you where to find information about this API (code https://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rest/ and documentation http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI)
(3) What extent of RESTification we are going to achieve for XEclipse? This is closely related to question (2). If REST API is available, the XEclipse RESTification will only need to construct the REST-ful request (i.e., @GET /rest/{space}/{page}) and parse result from server. If not, more work might be involved.
Indeed whay you say is part of the job. However XEclipse has an "abstraction layer" for the communication. This abstraction layer provides interfaces for retrievening and manipulating XWiki objects.
Now the main goals of the project is to provide an HTTP-based implementation of this layer so that XEclipse will be able to communicate to with XWiki using REST. This is of course the tip of the iceberg :)
Actually while "RESTifying" this we should also refactor where necessary and improve things. For example, one thing that comes to my mind is to enable lazy retrieval everywhere: we don't want to load in the interface thousands of items using a single request!
I hope that this answers your questions and if you have more don't hesitate to ask!
Cheers, Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Dear Eduard Moraru, Thanks a lot for your clarification. Today I have installed XWiki Enterprise 3.0 RC1 and XEclipse 1.2.0 RC1. XWiki URL is localhost:8080/xwiki/bin/view/Main/WebHome XEclipse connection URL is http://localhost:8080/xwiki/xmlrpc/confluence Now I can play around with Both XWiki and XEclipse. After looking at the details in the XEclipse RCP application, four plugins are available: 1. XWiki Eclipse 2. XWiki Eclipse Core Plug-in 3. XWiki Eclipse UI Plug-in 4. XWiki Eclipse XmlRpc Plug-in Does XEclipse RESTification mean that add an additional plugin, XWiki Eclipse REST Plug-in, to XEclipse bundle and provide similar function as the existing XmlRpc one? When a user creates a new connection to XWiki server, he/she needs to type in some URL like http://localhost:8080/xwiki/rest/confluence as an entry point in order to fetch the whole xwiki spaces? Best regards Jun Han On 03/24/2011 11:50 AM, Eduard Moraru wrote:
Hi Jun,
Glad to hear you're interested in XEclipse.
On 03/24/2011 04:47 PM, Jun Han wrote:
Dear Thomas and Fabio,
Thanks a lot for your prompt replies and they helped a lot to understand the project.
When I took a first thought about how to achieve RESTification, one thing popped out of my head is to add an abstract communication layer to XEclipse without touching its logic and user interface implementation. Considering the fact that XEclipse itself will be under major code refactoring in the project of "XEclipse editors improvement" as well, adding an abstract layer will make the two projects work in parallel without too much conflict. Given the fact that the two projects don`t really affect one another, you are pretty much free to experiment.
Besides that, you will be working on a separate fork of the XEclipse project (most likely in the sandbox svn directory http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/ ) which you will merge back when you are finished.
From Fabio's email, this abstract communication layer is already available for XEclipse,
Yes. You can find the interface and the two (local-Filesystem and remote-XML-RPC) implementations here http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse....
but it is not RESTful yet. Therefore, I will take a deeper look at the source code of XEclipse with two questions in mind: 1. figure out a way to refactor without affecting the logic and UI layer of XEclipse You could start by providing an implementation equivalent to RemoteXWikiDataStorage.java but which uses REST instead of XML-RPC, then work your way up by extending the IDataStorage.java interface with new functionality and provide the equivalent UI. 2. provide more support for logic layer, e.g., lazy initialization/retrieval
Best regards Jun Han Feel free to ask if you have any more questions.
Good luck, Eduard
On 03/24/2011 06:33 AM, Fabio Mancinelli wrote:
Hi Jun
On Wed, Mar 23, 2011 at 6:35 PM, Jun Han<[email protected]> wrote:
Hi, Everyone,
I am going to apply for student developer in GSoC 2011 and am interested in one of proposed XWiki projects, XEclipse "RESTification".
Glad to hear that you are interested in this project. Thomas has already replied to your questions but I will add some bits as one of the mentors of the project.
Currently I am a fourth year Ph.D. student in the department of Computer Science, University of Georgia, USA. My research focuses on Simulation/Modelling and Web services, and applies them to facilitate bioinformatics research.
My strengths are the following: (1). 6-year of Java programming experience including both desktop and web development and able to perform full lifecyle software development. (2). developed a SOAP Web service management system using Eclipse RCP and SWT
Very good.
(3). developed REST-ful Web services and integrated SOAP Web services from other collaborators (in German and Japan) to implement integrated scientific workflow following Web 2.0 standards
Very good.
After reading through the descriptions of proposed projects, XEclipse "RESTification" is of great interest to me. This project involves communication via SOAP and REST-ful Web services and is developed in Eclipse SWT platform, therefore, I might be a potential match for this project based on the skill set.
I have several questions regarding the requirement: (1) what is target development platform? The current XEclipse requires Eclipse Ganymede 3.4 and the most recent release is Eclipse 3.6 and 3.7. Is there any plan to support them?
The "requires Ganymede" is a leftover... When XEclipse was actively developed the most stable Eclipse version was 3.3 (hence the "require 3.4") I didn't try but I think that XEclipse should run without any problem on 3.7 right now.
Anyway the idea is to support the latest version of Eclipse, i.e. 3.7
(2) What is the current status of XWiki communication layer? From what I understand, SOAP + XML play a main role in the current system. Now XWiki is turning to REST eventually. I read some discussions on Mar 11 2011 about REST API in dev mail list, which mentioned that REST API is not there yet. Does this mean that the whole REST communication layer is not available yet?
Not quite right.
XWiki supports XMLRPC and REST. AFAIK, We don't have any "SOAPy" web services. I would say that XMLRPC is deprecated because it has several problems and limitations.
So the RESTful API is definitely the preferred mechanism for interacting with XWiki in a "machine oriented" way.
Thomas already told you where to find information about this API (code https://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rest/ and documentation http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI)
(3) What extent of RESTification we are going to achieve for XEclipse? This is closely related to question (2). If REST API is available, the XEclipse RESTification will only need to construct the REST-ful request (i.e., @GET /rest/{space}/{page}) and parse result from server. If not, more work might be involved.
Indeed whay you say is part of the job. However XEclipse has an "abstraction layer" for the communication. This abstraction layer provides interfaces for retrievening and manipulating XWiki objects.
Now the main goals of the project is to provide an HTTP-based implementation of this layer so that XEclipse will be able to communicate to with XWiki using REST. This is of course the tip of the iceberg :)
Actually while "RESTifying" this we should also refactor where necessary and improve things. For example, one thing that comes to my mind is to enable lazy retrieval everywhere: we don't want to load in the interface thousands of items using a single request!
I hope that this answers your questions and if you have more don't hesitate to ask!
Cheers, Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, On 03/29/2011 12:09 AM, Jun Han wrote: > Dear Eduard Moraru, > > Thanks a lot for your clarification. > > Today I have installed XWiki Enterprise 3.0 RC1 and XEclipse 1.2.0 RC1. > XWiki URL is localhost:8080/xwiki/bin/view/Main/WebHome > XEclipse connection URL is http://localhost:8080/xwiki/xmlrpc/confluence > > Now I can play around with Both XWiki and XEclipse. > > After looking at the details in the XEclipse RCP application, four > plugins are available: > 1. XWiki Eclipse AFAIK, http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse/ is the old version of XEclipse which is deprecated. > 2. XWiki Eclipse Core Plug-in http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.core/ contains core functionality like data model, storage, notifications, logging, etc. > 3. XWiki Eclipse UI Plug-in http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.ui/ depends on core and contains UI elements like views, editor, wizards, menus, etc. and works with the data model and storage defined in core. > 4. XWiki Eclipse XmlRpc Plug-in http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.xmlrpc/ is just an external dependency container plugin that holds XMLRPC jars needed by the XMLRPC implementation in core. There is no code here, the code is in core. Here you just have XWiki's XMLRPC client library that makes it easy to talk to XWiki trough XMLRPC. > Does XEclipse RESTification mean that add an additional plugin, XWiki > Eclipse REST Plug-in, to XEclipse bundle and provide similar function as > the existing XmlRpc one? It depends. It would be nice if you could externalize the storage system from core and make it pluggable trough eclipse plugins. If you make a system like that, it would mean that, in the UI plugin where you deppend on core, you would also depend on an external plugin (let's say org.xwiki.eclipse.core.storage.rest) that registers itself to be used by the storage service as a local or remote storage implementation. Regarding REST specific dependencies, you could have a plugin that does the same thing the XMLRPC plugin did, which is to hold binary dependencies. You could call it org.xwiki.eclipse.core.storage.rest.libs and put there any jars that will be needed by the rest implementation. > When a user creates a new connection to XWiki server, he/she needs to > type in some URL like http://localhost:8080/xwiki/rest/confluence as an > entry point in order to fetch the whole xwiki spaces? The rest endpoint for xwiki is http://.../xwiki/rest Obviously, the endpoint needs to be specified at connection creation time. The endpoint is implementation specific, so you could extend the storage interface to: - provide an example endpoint - test a given endpoint You use the example endpoint to fill in the UI for when displaying the new connection wizard to the user and then you test what the user enters to validate the wizard before creating a new connection. Depending how far you want to go, you might also add some additional connection options for storages that might need more than an endpoint and a user/password. Also, if there are more than one storage implementations available, you might want to let the user choose, when creating the new connection, which one to use. These are just some ideas of how it can be done. We're always opened to proposals :). Thanks, Eduard > Best regards > Jun Han > > On 03/24/2011 11:50 AM, Eduard Moraru wrote: >> Hi Jun, >> >> Glad to hear you're interested in XEclipse. >> >> On 03/24/2011 04:47 PM, Jun Han wrote: >>> Dear Thomas and Fabio, >>> >>> Thanks a lot for your prompt replies and they helped a lot to understand >>> the project. >>> >>> When I took a first thought about how to achieve RESTification, one >>> thing popped out of my head is to add an abstract communication layer to >>> XEclipse without touching its logic and user interface implementation. >>> Considering the fact that XEclipse itself will be under major code >>> refactoring in the project of "XEclipse editors improvement" as well, >>> adding an abstract layer will make the two projects work in parallel >>> without too much conflict. >> Given the fact that the two projects don`t really affect one another, >> you are pretty much free to experiment. >> >> Besides that, you will be working on a separate fork of the XEclipse >> project (most likely in the sandbox svn directory >> http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/ ) which you will >> merge back when you are finished. >>> From Fabio's email, this abstract communication layer is already >>> available for XEclipse, >> Yes. You can find the interface and the two (local-Filesystem and >> remote-XML-RPC) implementations here >> http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/ >>> but it is not RESTful yet. Therefore, I will >>> take a deeper look at the source code of XEclipse with two questions in >>> mind: >>> 1. figure out a way to refactor without affecting the logic and UI layer >>> of XEclipse >> You could start by providing an implementation equivalent to >> RemoteXWikiDataStorage.java but which uses REST instead of XML-RPC, then >> work your way up by extending the IDataStorage.java interface with new >> functionality and provide the equivalent UI. >>> 2. provide more support for logic layer, e.g., lazy initialization/retrieval >>> >>> Best regards >>> Jun Han >> Feel free to ask if you have any more questions. >> >> Good luck, >> Eduard >>> On 03/24/2011 06:33 AM, Fabio Mancinelli wrote: >>>> Hi Jun >>>> >>>> On Wed, Mar 23, 2011 at 6:35 PM, Jun Han<[email protected]> wrote: >>>>> Hi, Everyone, >>>>> >>>>> I am going to apply for student developer in GSoC 2011 and am interested >>>>> in one of proposed XWiki projects, XEclipse "RESTification". >>>>> >>>> Glad to hear that you are interested in this project. >>>> Thomas has already replied to your questions but I will add some bits >>>> as one of the mentors of the project. >>>> >>>>> Currently I am a fourth year Ph.D. student in the department of Computer >>>>> Science, University of Georgia, USA. My research focuses on >>>>> Simulation/Modelling and Web services, and applies them to facilitate >>>>> bioinformatics research. >>>>> >>>>> My strengths are the following: >>>>> (1). 6-year of Java programming experience including both desktop and >>>>> web development and able to perform full lifecyle software development. >>>>> (2). developed a SOAP Web service management system using Eclipse RCP >>>>> and SWT >>>>> >>>> Very good. >>>> >>>>> (3). developed REST-ful Web services and integrated SOAP Web services >>>>> from other collaborators (in German and Japan) to implement integrated >>>>> scientific workflow following Web 2.0 standards >>>>> >>>> Very good. >>>> >>>>> After reading through the descriptions of proposed projects, XEclipse >>>>> "RESTification" is of great interest to me. This project involves >>>>> communication via SOAP and REST-ful Web services and is developed in >>>>> Eclipse SWT platform, therefore, I might be a potential match for this >>>>> project based on the skill set. >>>>> >>>>> I have several questions regarding the requirement: >>>>> (1) what is target development platform? >>>>> The current XEclipse requires Eclipse Ganymede 3.4 and the most >>>>> recent release is Eclipse 3.6 and 3.7. Is there any plan to support them? >>>>> >>>> The "requires Ganymede" is a leftover... When XEclipse was actively >>>> developed the most stable Eclipse version was 3.3 (hence the "require >>>> 3.4") >>>> I didn't try but I think that XEclipse should run without any problem >>>> on 3.7 right now. >>>> >>>> Anyway the idea is to support the latest version of Eclipse, i.e. 3.7 >>>> >>>>> (2) What is the current status of XWiki communication layer? >>>>> From what I understand, SOAP + XML play a main role in the current >>>>> system. Now XWiki is turning to REST eventually. >>>>> I read some discussions on Mar 11 2011 about REST API in dev mail >>>>> list, which mentioned that REST API is not there yet. Does this mean >>>>> that the whole REST communication layer is not available yet? >>>>> >>>> Not quite right. >>>> >>>> XWiki supports XMLRPC and REST. AFAIK, We don't have any "SOAPy" web services. >>>> I would say that XMLRPC is deprecated because it has several problems >>>> and limitations. >>>> >>>> So the RESTful API is definitely the preferred mechanism for >>>> interacting with XWiki in a "machine oriented" way. >>>> >>>> Thomas already told you where to find information about this API (code >>>> https://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rest/ >>>> and documentation >>>> http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI) >>>> >>>>> (3) What extent of RESTification we are going to achieve for XEclipse? >>>>> This is closely related to question (2). If REST API is available, >>>>> the XEclipse RESTification will only need to construct the REST-ful >>>>> request (i.e., @GET /rest/{space}/{page}) and parse result from server. >>>>> If not, more work might be involved. >>>>> >>>> Indeed whay you say is part of the job. >>>> However XEclipse has an "abstraction layer" for the communication. >>>> This abstraction layer provides interfaces for retrievening and >>>> manipulating XWiki objects. >>>> >>>> Now the main goals of the project is to provide an HTTP-based >>>> implementation of this layer so that XEclipse will be able to >>>> communicate to with XWiki using REST. >>>> This is of course the tip of the iceberg :) >>>> >>>> Actually while "RESTifying" this we should also refactor where >>>> necessary and improve things. >>>> For example, one thing that comes to my mind is to enable lazy >>>> retrieval everywhere: we don't want to load in the interface thousands >>>> of items using a single request! >>>> >>>> I hope that this answers your questions and if you have more don't >>>> hesitate to ask! >>>> >>>> Cheers, >>>> Fabio >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
Dear all, Thanks a lot for your help. I have submitted the proposal to GSOC website. Any comments are welcome. From the Xwiki's GSOC project page, student applicants need to send a patch about JIRA issues. Do we student need to submit a patch and after that we can be qualified for further consideration? Best regards Jun Han On 03/29/2011 04:53 AM, Eduard Moraru wrote: > Hi Jun, > > On 03/29/2011 12:09 AM, Jun Han wrote: >> Dear Eduard Moraru, >> >> Thanks a lot for your clarification. >> >> Today I have installed XWiki Enterprise 3.0 RC1 and XEclipse 1.2.0 RC1. >> XWiki URL is localhost:8080/xwiki/bin/view/Main/WebHome >> XEclipse connection URL ishttp://localhost:8080/xwiki/xmlrpc/confluence >> >> Now I can play around with Both XWiki and XEclipse. >> >> After looking at the details in the XEclipse RCP application, four >> plugins are available: >> 1. XWiki Eclipse > AFAIK, > http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse/ > is the old version of XEclipse which is deprecated. >> 2. XWiki Eclipse Core Plug-in > http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.core/ > contains core functionality like data model, storage, notifications, > logging, etc. >> 3. XWiki Eclipse UI Plug-in > http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.ui/ > depends on core and contains UI elements like views, editor, wizards, > menus, etc. and works with the data model and storage defined in core. >> 4. XWiki Eclipse XmlRpc Plug-in > http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.xmlrpc/ > is just an external dependency container plugin that holds XMLRPC jars > needed by the XMLRPC implementation in core. There is no code here, the > code is in core. Here you just have XWiki's XMLRPC client library that > makes it easy to talk to XWiki trough XMLRPC. >> Does XEclipse RESTification mean that add an additional plugin, XWiki >> Eclipse REST Plug-in, to XEclipse bundle and provide similar function as >> the existing XmlRpc one? > It depends. It would be nice if you could externalize the storage system > from core and make it pluggable trough eclipse plugins. If you make a > system like that, it would mean that, in the UI plugin where you deppend > on core, you would also depend on an external plugin (let's say > org.xwiki.eclipse.core.storage.rest) that registers itself to be used by > the storage service as a local or remote storage implementation. > > Regarding REST specific dependencies, you could have a plugin that does > the same thing the XMLRPC plugin did, which is to hold binary > dependencies. You could call it org.xwiki.eclipse.core.storage.rest.libs > and put there any jars that will be needed by the rest implementation. >> When a user creates a new connection to XWiki server, he/she needs to >> type in some URL likehttp://localhost:8080/xwiki/rest/confluence as an >> entry point in order to fetch the whole xwiki spaces? > The rest endpoint for xwiki ishttp://.../xwiki/rest > Obviously, the endpoint needs to be specified at connection creation > time. The endpoint is implementation specific, so you could extend the > storage interface to: > - provide an example endpoint > - test a given endpoint > You use the example endpoint to fill in the UI for when displaying the > new connection wizard to the user and then you test what the user enters > to validate the wizard before creating a new connection. > > Depending how far you want to go, you might also add some additional > connection options for storages that might need more than an endpoint > and a user/password. > > Also, if there are more than one storage implementations available, you > might want to let the user choose, when creating the new connection, > which one to use. > > These are just some ideas of how it can be done. We're always opened to > proposals :). > > Thanks, > Eduard >> Best regards >> Jun Han >> >> On 03/24/2011 11:50 AM, Eduard Moraru wrote: >>> Hi Jun, >>> >>> Glad to hear you're interested in XEclipse. >>> >>> On 03/24/2011 04:47 PM, Jun Han wrote: >>>> Dear Thomas and Fabio, >>>> >>>> Thanks a lot for your prompt replies and they helped a lot to understand >>>> the project. >>>> >>>> When I took a first thought about how to achieve RESTification, one >>>> thing popped out of my head is to add an abstract communication layer to >>>> XEclipse without touching its logic and user interface implementation. >>>> Considering the fact that XEclipse itself will be under major code >>>> refactoring in the project of "XEclipse editors improvement" as well, >>>> adding an abstract layer will make the two projects work in parallel >>>> without too much conflict. >>> Given the fact that the two projects don`t really affect one another, >>> you are pretty much free to experiment. >>> >>> Besides that, you will be working on a separate fork of the XEclipse >>> project (most likely in the sandbox svn directory >>> http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/ ) which you will >>> merge back when you are finished. >>>> From Fabio's email, this abstract communication layer is already >>>> available for XEclipse, >>> Yes. You can find the interface and the two (local-Filesystem and >>> remote-XML-RPC) implementations here >>> http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/ >>>> but it is not RESTful yet. Therefore, I will >>>> take a deeper look at the source code of XEclipse with two questions in >>>> mind: >>>> 1. figure out a way to refactor without affecting the logic and UI layer >>>> of XEclipse >>> You could start by providing an implementation equivalent to >>> RemoteXWikiDataStorage.java but which uses REST instead of XML-RPC, then >>> work your way up by extending the IDataStorage.java interface with new >>> functionality and provide the equivalent UI. >>>> 2. provide more support for logic layer, e.g., lazy initialization/retrieval >>>> >>>> Best regards >>>> Jun Han >>> Feel free to ask if you have any more questions. >>> >>> Good luck, >>> Eduard >>>> On 03/24/2011 06:33 AM, Fabio Mancinelli wrote: >>>>> Hi Jun >>>>> >>>>> On Wed, Mar 23, 2011 at 6:35 PM, Jun Han<[email protected]> wrote: >>>>>> Hi, Everyone, >>>>>> >>>>>> I am going to apply for student developer in GSoC 2011 and am interested >>>>>> in one of proposed XWiki projects, XEclipse "RESTification". >>>>>> >>>>> Glad to hear that you are interested in this project. >>>>> Thomas has already replied to your questions but I will add some bits >>>>> as one of the mentors of the project. >>>>> >>>>>> Currently I am a fourth year Ph.D. student in the department of Computer >>>>>> Science, University of Georgia, USA. My research focuses on >>>>>> Simulation/Modelling and Web services, and applies them to facilitate >>>>>> bioinformatics research. >>>>>> >>>>>> My strengths are the following: >>>>>> (1). 6-year of Java programming experience including both desktop and >>>>>> web development and able to perform full lifecyle software development. >>>>>> (2). developed a SOAP Web service management system using Eclipse RCP >>>>>> and SWT >>>>>> >>>>> Very good. >>>>> >>>>>> (3). developed REST-ful Web services and integrated SOAP Web services >>>>>> from other collaborators (in German and Japan) to implement integrated >>>>>> scientific workflow following Web 2.0 standards >>>>>> >>>>> Very good. >>>>> >>>>>> After reading through the descriptions of proposed projects, XEclipse >>>>>> "RESTification" is of great interest to me. This project involves >>>>>> communication via SOAP and REST-ful Web services and is developed in >>>>>> Eclipse SWT platform, therefore, I might be a potential match for this >>>>>> project based on the skill set. >>>>>> >>>>>> I have several questions regarding the requirement: >>>>>> (1) what is target development platform? >>>>>> The current XEclipse requires Eclipse Ganymede 3.4 and the most >>>>>> recent release is Eclipse 3.6 and 3.7. Is there any plan to support them? >>>>>> >>>>> The "requires Ganymede" is a leftover... When XEclipse was actively >>>>> developed the most stable Eclipse version was 3.3 (hence the "require >>>>> 3.4") >>>>> I didn't try but I think that XEclipse should run without any problem >>>>> on 3.7 right now. >>>>> >>>>> Anyway the idea is to support the latest version of Eclipse, i.e. 3.7 >>>>> >>>>>> (2) What is the current status of XWiki communication layer? >>>>>> From what I understand, SOAP + XML play a main role in the current >>>>>> system. Now XWiki is turning to REST eventually. >>>>>> I read some discussions on Mar 11 2011 about REST API in dev mail >>>>>> list, which mentioned that REST API is not there yet. Does this mean >>>>>> that the whole REST communication layer is not available yet? >>>>>> >>>>> Not quite right. >>>>> >>>>> XWiki supports XMLRPC and REST. AFAIK, We don't have any "SOAPy" web services. >>>>> I would say that XMLRPC is deprecated because it has several problems >>>>> and limitations. >>>>> >>>>> So the RESTful API is definitely the preferred mechanism for >>>>> interacting with XWiki in a "machine oriented" way. >>>>> >>>>> Thomas already told you where to find information about this API (code >>>>> https://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rest/ >>>>> and documentation >>>>> http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI) >>>>> >>>>>> (3) What extent of RESTification we are going to achieve for XEclipse? >>>>>> This is closely related to question (2). If REST API is available, >>>>>> the XEclipse RESTification will only need to construct the REST-ful >>>>>> request (i.e., @GET /rest/{space}/{page}) and parse result from server. >>>>>> If not, more work might be involved. >>>>>> >>>>> Indeed whay you say is part of the job. >>>>> However XEclipse has an "abstraction layer" for the communication. >>>>> This abstraction layer provides interfaces for retrievening and >>>>> manipulating XWiki objects. >>>>> >>>>> Now the main goals of the project is to provide an HTTP-based >>>>> implementation of this layer so that XEclipse will be able to >>>>> communicate to with XWiki using REST. >>>>> This is of course the tip of the iceberg :) >>>>> >>>>> Actually while "RESTifying" this we should also refactor where >>>>> necessary and improve things. >>>>> For example, one thing that comes to my mind is to enable lazy >>>>> retrieval everywhere: we don't want to load in the interface thousands >>>>> of items using a single request! >>>>> >>>>> I hope that this answers your questions and if you have more don't >>>>> hesitate to ask! >>>>> >>>>> Cheers, >>>>> Fabio >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, On 04/05/2011 05:29 AM, Jun Han wrote: > Dear all, > > Thanks a lot for your help. > I have submitted the proposal to GSOC website. > Any comments are welcome. > > From the Xwiki's GSOC project page, student applicants need to send a > patch about JIRA issues. > Do we student need to submit a patch and after that we can be qualified > for further consideration? If you take a good look at XWiki's GSoC page, it says that the submission of patches should be done "from April 25th to May 23rd**" which is the "Community Bonding Period" that comes after the accepted students list is announced. (check the GSoC timeline at http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline ) So no, the patch thing is not necessarily for evaluation, since the student is already accepted by then. It's more for helping students understand XWiki's code and making sure they respect code conventions, etc. > Best regards > Jun Han > > On 03/29/2011 04:53 AM, Eduard Moraru wrote: >> Hi Jun, >> >> On 03/29/2011 12:09 AM, Jun Han wrote: >>> Dear Eduard Moraru, >>> >>> Thanks a lot for your clarification. >>> >>> Today I have installed XWiki Enterprise 3.0 RC1 and XEclipse 1.2.0 RC1. >>> XWiki URL is localhost:8080/xwiki/bin/view/Main/WebHome >>> XEclipse connection URL ishttp://localhost:8080/xwiki/xmlrpc/confluence >>> >>> Now I can play around with Both XWiki and XEclipse. >>> >>> After looking at the details in the XEclipse RCP application, four >>> plugins are available: >>> 1. XWiki Eclipse >> AFAIK, >> http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse/ >> is the old version of XEclipse which is deprecated. >>> 2. XWiki Eclipse Core Plug-in >> http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.core/ >> contains core functionality like data model, storage, notifications, >> logging, etc. >>> 3. XWiki Eclipse UI Plug-in >> http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.ui/ >> depends on core and contains UI elements like views, editor, wizards, >> menus, etc. and works with the data model and storage defined in core. >>> 4. XWiki Eclipse XmlRpc Plug-in >> http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.xmlrpc/ >> is just an external dependency container plugin that holds XMLRPC jars >> needed by the XMLRPC implementation in core. There is no code here, the >> code is in core. Here you just have XWiki's XMLRPC client library that >> makes it easy to talk to XWiki trough XMLRPC. >>> Does XEclipse RESTification mean that add an additional plugin, XWiki >>> Eclipse REST Plug-in, to XEclipse bundle and provide similar function as >>> the existing XmlRpc one? >> It depends. It would be nice if you could externalize the storage system >> from core and make it pluggable trough eclipse plugins. If you make a >> system like that, it would mean that, in the UI plugin where you deppend >> on core, you would also depend on an external plugin (let's say >> org.xwiki.eclipse.core.storage.rest) that registers itself to be used by >> the storage service as a local or remote storage implementation. >> >> Regarding REST specific dependencies, you could have a plugin that does >> the same thing the XMLRPC plugin did, which is to hold binary >> dependencies. You could call it org.xwiki.eclipse.core.storage.rest.libs >> and put there any jars that will be needed by the rest implementation. >>> When a user creates a new connection to XWiki server, he/she needs to >>> type in some URL likehttp://localhost:8080/xwiki/rest/confluence as an >>> entry point in order to fetch the whole xwiki spaces? >> The rest endpoint for xwiki ishttp://.../xwiki/rest >> Obviously, the endpoint needs to be specified at connection creation >> time. The endpoint is implementation specific, so you could extend the >> storage interface to: >> - provide an example endpoint >> - test a given endpoint >> You use the example endpoint to fill in the UI for when displaying the >> new connection wizard to the user and then you test what the user enters >> to validate the wizard before creating a new connection. >> >> Depending how far you want to go, you might also add some additional >> connection options for storages that might need more than an endpoint >> and a user/password. >> >> Also, if there are more than one storage implementations available, you >> might want to let the user choose, when creating the new connection, >> which one to use. >> >> These are just some ideas of how it can be done. We're always opened to >> proposals :). >> >> Thanks, >> Eduard >>> Best regards >>> Jun Han >>> >>> On 03/24/2011 11:50 AM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> Glad to hear you're interested in XEclipse. >>>> >>>> On 03/24/2011 04:47 PM, Jun Han wrote: >>>>> Dear Thomas and Fabio, >>>>> >>>>> Thanks a lot for your prompt replies and they helped a lot to understand >>>>> the project. >>>>> >>>>> When I took a first thought about how to achieve RESTification, one >>>>> thing popped out of my head is to add an abstract communication layer to >>>>> XEclipse without touching its logic and user interface implementation. >>>>> Considering the fact that XEclipse itself will be under major code >>>>> refactoring in the project of "XEclipse editors improvement" as well, >>>>> adding an abstract layer will make the two projects work in parallel >>>>> without too much conflict. >>>> Given the fact that the two projects don`t really affect one another, >>>> you are pretty much free to experiment. >>>> >>>> Besides that, you will be working on a separate fork of the XEclipse >>>> project (most likely in the sandbox svn directory >>>> http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/ ) which you will >>>> merge back when you are finished. >>>>> From Fabio's email, this abstract communication layer is already >>>>> available for XEclipse, >>>> Yes. You can find the interface and the two (local-Filesystem and >>>> remote-XML-RPC) implementations here >>>> http://svn.xwiki.org/svnroot/xwiki/xeclipse/trunk/plugins/org.xwiki.eclipse.core/src/main/java/org/xwiki/eclipse/core/storage/ >>>>> but it is not RESTful yet. Therefore, I will >>>>> take a deeper look at the source code of XEclipse with two questions in >>>>> mind: >>>>> 1. figure out a way to refactor without affecting the logic and UI layer >>>>> of XEclipse >>>> You could start by providing an implementation equivalent to >>>> RemoteXWikiDataStorage.java but which uses REST instead of XML-RPC, then >>>> work your way up by extending the IDataStorage.java interface with new >>>> functionality and provide the equivalent UI. >>>>> 2. provide more support for logic layer, e.g., lazy initialization/retrieval >>>>> >>>>> Best regards >>>>> Jun Han >>>> Feel free to ask if you have any more questions. >>>> >>>> Good luck, >>>> Eduard >>>>> On 03/24/2011 06:33 AM, Fabio Mancinelli wrote: >>>>>> Hi Jun >>>>>> >>>>>> On Wed, Mar 23, 2011 at 6:35 PM, Jun Han<[email protected]> wrote: >>>>>>> Hi, Everyone, >>>>>>> >>>>>>> I am going to apply for student developer in GSoC 2011 and am interested >>>>>>> in one of proposed XWiki projects, XEclipse "RESTification". >>>>>>> >>>>>> Glad to hear that you are interested in this project. >>>>>> Thomas has already replied to your questions but I will add some bits >>>>>> as one of the mentors of the project. >>>>>> >>>>>>> Currently I am a fourth year Ph.D. student in the department of Computer >>>>>>> Science, University of Georgia, USA. My research focuses on >>>>>>> Simulation/Modelling and Web services, and applies them to facilitate >>>>>>> bioinformatics research. >>>>>>> >>>>>>> My strengths are the following: >>>>>>> (1). 6-year of Java programming experience including both desktop and >>>>>>> web development and able to perform full lifecyle software development. >>>>>>> (2). developed a SOAP Web service management system using Eclipse RCP >>>>>>> and SWT >>>>>>> >>>>>> Very good. >>>>>> >>>>>>> (3). developed REST-ful Web services and integrated SOAP Web services >>>>>>> from other collaborators (in German and Japan) to implement integrated >>>>>>> scientific workflow following Web 2.0 standards >>>>>>> >>>>>> Very good. >>>>>> >>>>>>> After reading through the descriptions of proposed projects, XEclipse >>>>>>> "RESTification" is of great interest to me. This project involves >>>>>>> communication via SOAP and REST-ful Web services and is developed in >>>>>>> Eclipse SWT platform, therefore, I might be a potential match for this >>>>>>> project based on the skill set. >>>>>>> >>>>>>> I have several questions regarding the requirement: >>>>>>> (1) what is target development platform? >>>>>>> The current XEclipse requires Eclipse Ganymede 3.4 and the most >>>>>>> recent release is Eclipse 3.6 and 3.7. Is there any plan to support them? >>>>>>> >>>>>> The "requires Ganymede" is a leftover... When XEclipse was actively >>>>>> developed the most stable Eclipse version was 3.3 (hence the "require >>>>>> 3.4") >>>>>> I didn't try but I think that XEclipse should run without any problem >>>>>> on 3.7 right now. >>>>>> >>>>>> Anyway the idea is to support the latest version of Eclipse, i.e. 3.7 >>>>>> >>>>>>> (2) What is the current status of XWiki communication layer? >>>>>>> From what I understand, SOAP + XML play a main role in the current >>>>>>> system. Now XWiki is turning to REST eventually. >>>>>>> I read some discussions on Mar 11 2011 about REST API in dev mail >>>>>>> list, which mentioned that REST API is not there yet. Does this mean >>>>>>> that the whole REST communication layer is not available yet? >>>>>>> >>>>>> Not quite right. >>>>>> >>>>>> XWiki supports XMLRPC and REST. AFAIK, We don't have any "SOAPy" web services. >>>>>> I would say that XMLRPC is deprecated because it has several problems >>>>>> and limitations. >>>>>> >>>>>> So the RESTful API is definitely the preferred mechanism for >>>>>> interacting with XWiki in a "machine oriented" way. >>>>>> >>>>>> Thomas already told you where to find information about this API (code >>>>>> https://svn.xwiki.org/svnroot/xwiki/platform/core/trunk/xwiki-rest/ >>>>>> and documentation >>>>>> http://platform.xwiki.org/xwiki/bin/view/Features/XWikiRESTfulAPI) >>>>>> >>>>>>> (3) What extent of RESTification we are going to achieve for XEclipse? >>>>>>> This is closely related to question (2). If REST API is available, >>>>>>> the XEclipse RESTification will only need to construct the REST-ful >>>>>>> request (i.e., @GET /rest/{space}/{page}) and parse result from server. >>>>>>> If not, more work might be involved. >>>>>>> >>>>>> Indeed whay you say is part of the job. >>>>>> However XEclipse has an "abstraction layer" for the communication. >>>>>> This abstraction layer provides interfaces for retrievening and >>>>>> manipulating XWiki objects. >>>>>> >>>>>> Now the main goals of the project is to provide an HTTP-based >>>>>> implementation of this layer so that XEclipse will be able to >>>>>> communicate to with XWiki using REST. >>>>>> This is of course the tip of the iceberg :) >>>>>> >>>>>> Actually while "RESTifying" this we should also refactor where >>>>>> necessary and improve things. >>>>>> For example, one thing that comes to my mind is to enable lazy >>>>>> retrieval everywhere: we don't want to load in the interface thousands >>>>>> of items using a single request! >>>>>> >>>>>> I hope that this answers your questions and if you have more don't >>>>>> hesitate to ask! >>>>>> >>>>>> Cheers, >>>>>> Fabio >>>>>> _______________________________________________ >>>>>> devs mailing list >>>>>> [email protected] >>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> _______________________________________________ >>>>> devs mailing list >>>>> [email protected] >>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>> _______________________________________________ >>>> devs mailing list >>>> [email protected] >>>> http://lists.xwiki.org/mailman/listinfo/devs >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >>> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs >
participants (4)
-
Eduard Moraru -
Fabio Mancinelli -
Jun Han -
Thomas Mortagne