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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
