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