[xwiki-devs] [GSoC 2011] Self Introduction and Interested Project XEclipse "RESTification"

Eduard Moraru eduard.moraru at xwiki.com
Tue Mar 29 08:53:07 UTC 2011

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
is the old version of XEclipse which is deprecated.
> 2. XWiki Eclipse Core Plug-in
contains core functionality like data model, storage, notifications, 
logging, etc.
> 3. XWiki Eclipse UI Plug-in
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
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 :).

> 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<jun.han37 at gmail.com>     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
>>>> devs at xwiki.org
>>>> http://lists.xwiki.org/mailman/listinfo/devs
>>> _______________________________________________
>>> devs mailing list
>>> devs at xwiki.org
>>> http://lists.xwiki.org/mailman/listinfo/devs
>> _______________________________________________
>> devs mailing list
>> devs at xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> devs at xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

More information about the devs mailing list