23 Mar
2011
23 Mar
'11
6:35 p.m.
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/
23 Mar
23 Mar
6:45 p.m.
New subject: [xwiki-devs] [GSoC 2011] Self Introduction and Interested Project
Hi,
On Wed, Mar 23, 2011 at 18:35, Jun Han <jun.han37(a)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".
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
24 Mar
24 Mar
11:33 a.m.
New subject: [xwiki-devs] [GSoC 2011] Self Introduction and Interested Project
Hi Jun
On Wed, Mar 23, 2011 at 6:35 PM, Jun Han <jun.han37(a)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
3:47 p.m.
New subject: [xwiki-devs] [GSoC 2011] Self Introduction and Interested Project
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<jun.han37(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
4:50 p.m.
New subject: [xwiki-devs] [GSoC 2011] Self Introduction and Interested Project
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<jun.han37(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
28 Mar
28 Mar
11:09 p.m.
New subject: [xwiki-devs] [GSoC 2011] Self Introduction and Interested Project XEclipse "RESTification"
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi Jun
On Wed, Mar 23, 2011 at 6:35 PM, Jun Han<jun.han37(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
29 Mar
29 Mar
10:53 a.m.
New subject: [xwiki-devs] [GSoC 2011] Self Introduction and Interested Project XEclipse "RESTification"
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…
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…
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…
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs Hi Jun
On Wed, Mar 23, 2011 at 6:35 PM, Jun Han<jun.han37(a)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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5 Apr
5 Apr
4:29 a.m.
New subject: [xwiki-devs] [GSoC 2011] Self Introduction and Interested Project XEclipse "RESTification"
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…
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…
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…
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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<jun.han37(a)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(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:40 p.m.
New subject: [xwiki-devs] [GSoC 2011] Self Introduction and Interested Project XEclipse "RESTification"
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/ti…
)
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
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 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…
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…
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…
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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
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<jun.han37(a)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(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4913
days inactive
4926
days old
8 comments
4 participants
participants (4)
-
Eduard Moraru -
Fabio Mancinelli -
Jun Han -
Thomas Mortagne