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.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
