Hi Jun, login/logout can be implemented in order to store on the client side user credentials that are sent with HTTP requests. Currently there is no way in the REST-api to get a "session token" (like the cookie sent after a login is made using the web form) so that subsequent requests are performed on the behalf of a previously authenticated user. So what is usually done is to send basic-auth credentials with each request. You can start with this. Next you might try to retrieve the cookie by faking a standard login and using that cookie in subsequent requests. The ideal setting would be to implement server side some OAuth-like mechanism, but this is out of scope wrt your project. -Fabio On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<jun.han37(a)gmail.com> wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jun, the REST api also takes into account Wikis, so you should take into account this into the plugin.

-Fabio On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<jun.han37(a)gmail.com> wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Eduard and Fabio, Thanks a lot for your suggestions. I managed to create a top-level tree expansion when user requests the entry point of REST API: localhost:8080/xwiki/rest. A screenshot is available at: http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png Now the labels display the whole <href> attribute, I plan to "syntaxes" and "wikis" later on. When user clicks the "wikis", the navigation tree will continue to expand to show all the sub-wiki names. It took me a while to figure out the configuration of tree content provider, tree viewer and label provider, which is a little different with what I did in Eclipse SWT development. As this has been sorted out, I would pick up the pace. Best regards Jun Han On 06/07/2011 10:37 AM, Eduard Moraru wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jun, On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: I think that you should make the "wikis" implicit as well and leave only the Connection Name as top root, just like in my previous proposal: Connection01 - wiki1 -- spaceA --- pageX - wiki2 - etc. As Fabio pointed out, stuff like supported syntaxes and xwiki version should be displayed in the properties page of a connection. Also, you need to take care when the user enters the user name and password and consider the wiki for which it applies. User Admin on the main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 (subwiki1:XWiki.Admin). I believe that, if you don`t enter the absolute user name (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it will be resolved to the wiki of the resource you are trying to access. You should, at least internally, always use absolute user names. Thanks, Eduard _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jun, On 06/10/2011 05:26 PM, Jun Han wrote: I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. It should not take that much of a refactoring on the UI part, since the heavy lifting is done in the core. What I actually wanted to tell you is that you should take the refactoring in a modular direction and consider your work as a contribution and alternative for the existing system and not only as a replacement. I you can`t do it as a contribution, consider adding a mechanism that allows you to do so (see our first discussions on integrating the rest back-end). Keep the abstraction layer (interfaces, model, etc) as the main think the ui and even core components communicate with and keep the implementation of that abstraction layer pluggable (xml-rpc, rest, etc). The UI must also be aware of this and act accordingly. We don`t want to do the same replacement work if, for whatever reason, we want to switch to a different back-end in the future. So keep that in mind at all time during GSoC. Besides that, keep up the good work ;) Thanks, Eduard _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jun, Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc. So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page) Cheers, Eduard On Fri, Jun 10, 2011 at 7:52 PM, Jun Han&lt;jun.han37(a)gmail.com&gt; wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Dear all, After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation. Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions. If my understanding is correct, I will begin re-factoring work. Best regards Jun Han On 6/11/2011 10:32 AM, Eduard Moraru wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jun, could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!) Midterm is approaching so we need to make things advance a little bit faster. Thanks, Fabio On Mon, Jun 13, 2011 at 9:00 AM, Jun Han&lt;jun.han37(a)gmail.com&gt; wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi there, I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends? IMO we should only use one and use the REST API only. If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. Thanks -Vincent On Jun 19, 2011, at 6:52 AM, Jun Han wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jun, thanks, for the update. I agree with Vincent... The backend should not be an explicit choice made for each connection. REST should be the default and if you need XMLRPC (for example for connecting to a veeeery old XWiki instance) you might have an advanced button that allows you to do this or, as you suggested, the URI might suggest the backend to use.

You should progress on the REST aspects asap though. Thanks, Fabio On Sun, Jun 19, 2011 at 4:57 PM, Jun Han &lt;jun.han37(a)gmail.com&gt; wrote: > Hi Vincent, > > Thanks a lot for your suggestion. > > IMHO, xmlrpc is included for the purpose of back-ward compatibility. > As REST API was first introduced in version 1.8 from xwiki jira, > xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., > v1.4 or v1.5). > > I agree that technical details should not be exposed to end user. > > The backend implementation may be determined via analyzing user input of > server endpoint. For example, if the serverurl contains "confluence" > (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If > it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest > is used. > > However, the current implementation will populate the specific server > url field according to the backend type (xmlrpc or rest). > There may be some better way to do this. > > Best regards > > Jun Han > > On 06/19/2011 03:40 AM, Vincent Massol wrote: >> Hi there, >> >> I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? >> Also why do we want to have to maintain several backends? >> >> IMO we should only use one and use the REST API only. >> >> If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. >> >> The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. >> >> Thanks >> -Vincent >> >> On Jun 19, 2011, at 6:52 AM, Jun Han wrote: >> >>> Hi Fabio, >>> >>> I have already finished re-factoring the whole xmlrpc backend. >>> >>> A new combo list is added to the "new connection" wizard to provide two >>> choices (xmlrpc and rest), as shown in >>> http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. >>> >>> When user selects "xmlrpc", the xmlrpc implementation is used. The >>> navigation panel can show the xwiki resources, as shown in >>> http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. >>> >>> I will continue working on the rest backend following the previous >>> discussion. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >>>> Hi Jun, >>>> >>>> could you post a status about your work? >>>> Your commits stream >>>> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >>>> informative (are you holding commits locally? If so you should push >>>> more frequently!) >>>> >>>> Midterm is approaching so we need to make things advance a little bit faster. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han&lt;jun.han37(a)gmail.com&gt; wrote: >>>>> Dear all, >>>>> >>>>> After I looked into the current implementation of XEclipse and tried >>>>> several attempts, one plan, whose goal is to provide an abstract >>>>> communication layer between XEclipse and server, might be feasible. >>>>> A rough system diagram showing the relationships of plugins of XWiki >>>>> Eclipse is available at: >>>>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>>>> >>>>> In order to remove dependency of particular back-end implementation >>>>> (xmlrpc or rest), >>>>> an abstract layer, which includes two plugins (model and storage) will >>>>> be created. >>>>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>>>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>>>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>>>> >>>>> In this way, all the core implementation and UI components (dialogs, >>>>> properties dialog, adapters) in ui plugin will now depend on the model >>>>> and storage plugins rather than the xmlrpc implementation. >>>>> >>>>> Instead of only providing the required jar files, xmlrpc and rest >>>>> plugins will also do the following: >>>>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>>>> storage plugin >>>>> 2. extend the model classes in model plugin >>>>> >>>>> In this way, all the abstract classes in model and storage plugins will >>>>> be initialized in the run time and perform the specified functions. >>>>> >>>>> If my understanding is correct, I will begin re-factoring work. >>>>> >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> Instead of returning Object, you should return >>>>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>>>> >>>>>> So the storage abstraction needs to include and abstract model as well in >>>>>> order to be usable. This means that the implementation also comes with a >>>>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>>>> org.xwiki.eclipse.core.model.Page) >>>>>> >>>>>> Cheers, >>>>>> Eduard >>>>>> >>>>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han&lt;jun.han37(a)gmail.com&gt; wrote: >>>>>> >>>>>>> Hi Eduard, >>>>>>> >>>>>>> Thanks a lot for prompt instruction. >>>>>>> >>>>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>>>> >>>>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>>>> to devise a common storage API for both of them. >>>>>>> >>>>>>> For example, >>>>>>> public Object getPage(String pageId) >>>>>>> public List<Object> getPages(String spaceKey) >>>>>>> >>>>>>> They will return >>>>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>>>> >>>>>>> If this is the way to go, I will look more into how to implement this. >>>>>>> Adapter pattern may be used. >>>>>>> >>>>>>> Best regards >>>>>>> >>>>>>> Jun Han >>>>>>> >>>>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>>>> Hi, Eduard and Fabio, >>>>>>>>> >>>>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>>>> wiki, space. >>>>>>>>> Please see the screenshot at >>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>>>> I think it's from an early stage of development. >>>>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>>>> >>>>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>>>> other dialog windows related to connection, wiki, space. >>>>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>>>> heavy lifting is done in the core. >>>>>>>> >>>>>>>> What I actually wanted to tell you is that you should take the >>>>>>>> refactoring in a modular direction and consider your work as a >>>>>>>> contribution and alternative for the existing system and not only as a >>>>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>>>> mechanism that allows you to do so (see our first discussions on >>>>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>>>> model, etc) as the main think the ui and even core components >>>>>>>> communicate with and keep the implementation of that abstraction layer >>>>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>>>> act accordingly. >>>>>>>> >>>>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>>>> mind at all time during GSoC. >>>>>>>> >>>>>>>> Besides that, keep up the good work ;) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Eduard >>>>>>>>> Best regards >>>>>>>>> Jun Han >>>>>>>>> >>>>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>>>> would show this information in the property panel of the connection. >>>>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>>>> only >>>>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>>>> >>>>>>>>>> Connection01 >>>>>>>>>> - wiki1 >>>>>>>>>> -- spaceA >>>>>>>>>> --- pageX >>>>>>>>>> - wiki2 >>>>>>>>>> - etc. >>>>>>>>>> >>>>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>>>> should be displayed in the properties page of a connection. >>>>>>>>>> >>>>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Eduard >>>>>>>>>>> Thanks, >>>>>>>>>>> Fabio >>>>>>>>>>> >>>>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han&lt;jun.han37(a)gmail.com&gt; >>>>>>> wrote: >>>>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>>>> >>>>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>>>> >>>>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>>>> >>>>>>>>>>>> A screenshot is available at: >>>>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>>>> >>>>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>>>> "syntaxes" >>>>>>>>>>>> and "wikis" later on. >>>>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>>>> >>>>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>>>> out, >>>>>>>>>>>> I would pick up the pace. >>>>>>>>>>>> >>>>>>>>>>>> Best regards >>>>>>>>>>>> Jun Han >>>>>>>>>>>> >>>>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>> >>>>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>>>> account this into the plugin. >>>>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>>>> do >>>>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>>>> >>>>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>>>> >>>>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>>>> ---- Main >>>>>>>>>>>>> ------ WebHome >>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>> ---------- 0 >>>>>>>>>>>>> ---------- 1 >>>>>>>>>>>>> ---------- 2 >>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>> ---------- 0 >>>>>>>>>>>>> ---------- 1 >>>>>>>>>>>>> etc. >>>>>>>>>>>>> >>>>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>>>> change >>>>>>>>>>>>> to some other IDs. >>>>>>>>>>>>> >>>>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>>>> have >>>>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>>>> easier management of the objects. >>>>>>>>>>>>> >>>>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>>>> >>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>>> etc. >>>>>>>>>>>>> >>>>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>>>> class like: >>>>>>>>>>>>> >>>>>>>>>>>>> ------ WebHome >>>>>>>>>>>>> -------- Attachments >>>>>>>>>>>>> ---------- dog.png >>>>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>>> etc. >>>>>>>>>>>>> >>>>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>>>> again the API specs. >>>>>>>>>>>>> >>>>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>>>> new >>>>>>>>>>>>> stuff. :) >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Eduard >>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han&lt;jun.han37(a)gmail.com&gt; >>>>>>> wrote: >>>>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>>>> functionality >>>>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>>>> means >>>>>>>>>>>>>>> login fails. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>>>> code >>>>>>>>>>>>>>> accordingly. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>>>> panel, >>>>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>>>> them? >>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Jun Han >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>>>> side >>>>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>>>> token" >>>>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>>>> so >>>>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>>>> previously >>>>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>>>> each request. >>>>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>>>> cookie by >>>>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>>>> requests. >>>>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>>>> OAuth-like >>>>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han&lt;jun.han37(a)gmail.com&gt; >>>>>>> wrote: >>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>>>> functionality >>>>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>>>> something like: >>>>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>>>> HTTP >>>>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>>>> the response. >>>>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>>>> Jun Han

On Mon, Jun 20, 2011 at 10:48, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: Isn't XMLRPC support used to mean Confluence support ? I really don't care about Confluence support if you ask me, just making sure we are taking everything into account. > > Thanks > -Vincent > >> You should progress on the REST aspects asap though. >> >> Thanks, >> Fabio >> >> On Sun, Jun 19, 2011 at 4:57 PM, Jun Han &lt;jun.han37(a)gmail.com&gt; wrote: >>> Hi Vincent, >>> >>> Thanks a lot for your suggestion. >>> >>> IMHO, xmlrpc is included for the purpose of back-ward compatibility. >>> As REST API was first introduced in version 1.8 from xwiki jira, >>> xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., >>> v1.4 or v1.5). >>> >>> I agree that technical details should not be exposed to end user. >>> >>> The backend implementation may be determined via analyzing user input of >>> server endpoint. For example, if the serverurl contains "confluence" >>> (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If >>> it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest >>> is used. >>> >>> However, the current implementation will populate the specific server >>> url field according to the backend type (xmlrpc or rest). >>> There may be some better way to do this. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 06/19/2011 03:40 AM, Vincent Massol wrote: >>>> Hi there, >>>> >>>> I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? >>>> Also why do we want to have to maintain several backends? >>>> >>>> IMO we should only use one and use the REST API only. >>>> >>>> If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. >>>> >>>> The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. >>>> >>>> Thanks >>>> -Vincent >>>> >>>> On Jun 19, 2011, at 6:52 AM, Jun Han wrote: >>>> >>>>> Hi Fabio, >>>>> >>>>> I have already finished re-factoring the whole xmlrpc backend. >>>>> >>>>> A new combo list is added to the "new connection" wizard to provide two >>>>> choices (xmlrpc and rest), as shown in >>>>> http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. >>>>> >>>>> When user selects "xmlrpc", the xmlrpc implementation is used. The >>>>> navigation panel can show the xwiki resources, as shown in >>>>> http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. >>>>> >>>>> I will continue working on the rest backend following the previous >>>>> discussion. >>>>> >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >>>>>> Hi Jun, >>>>>> >>>>>> could you post a status about your work? >>>>>> Your commits stream >>>>>> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >>>>>> informative (are you holding commits locally? If so you should push >>>>>> more frequently!) >>>>>> >>>>>> Midterm is approaching so we need to make things advance a little bit faster. >>>>>> >>>>>> Thanks, >>>>>> Fabio >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han&lt;jun.han37(a)gmail.com&gt; wrote: >>>>>>> Dear all, >>>>>>> >>>>>>> After I looked into the current implementation of XEclipse and tried >>>>>>> several attempts, one plan, whose goal is to provide an abstract >>>>>>> communication layer between XEclipse and server, might be feasible. >>>>>>> A rough system diagram showing the relationships of plugins of XWiki >>>>>>> Eclipse is available at: >>>>>>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>>>>>> >>>>>>> In order to remove dependency of particular back-end implementation >>>>>>> (xmlrpc or rest), >>>>>>> an abstract layer, which includes two plugins (model and storage) will >>>>>>> be created. >>>>>>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>>>>>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>>>>>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>>>>>> >>>>>>> In this way, all the core implementation and UI components (dialogs, >>>>>>> properties dialog, adapters) in ui plugin will now depend on the model >>>>>>> and storage plugins rather than the xmlrpc implementation. >>>>>>> >>>>>>> Instead of only providing the required jar files, xmlrpc and rest >>>>>>> plugins will also do the following: >>>>>>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>>>>>> storage plugin >>>>>>> 2. extend the model classes in model plugin >>>>>>> >>>>>>> In this way, all the abstract classes in model and storage plugins will >>>>>>> be initialized in the run time and perform the specified functions. >>>>>>> >>>>>>> If my understanding is correct, I will begin re-factoring work. >>>>>>> >>>>>>> Best regards >>>>>>> >>>>>>> Jun Han >>>>>>> >>>>>>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> Instead of returning Object, you should return >>>>>>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>>>>>> >>>>>>>> So the storage abstraction needs to include and abstract model as well in >>>>>>>> order to be usable. This means that the implementation also comes with a >>>>>>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>>>>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>>>>>> org.xwiki.eclipse.core.model.Page) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Eduard >>>>>>>> >>>>>>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han&lt;jun.han37(a)gmail.com&gt; wrote: >>>>>>>> >>>>>>>>> Hi Eduard, >>>>>>>>> >>>>>>>>> Thanks a lot for prompt instruction. >>>>>>>>> >>>>>>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>>>>>> >>>>>>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>>>>>> to devise a common storage API for both of them. >>>>>>>>> >>>>>>>>> For example, >>>>>>>>> public Object getPage(String pageId) >>>>>>>>> public List<Object> getPages(String spaceKey) >>>>>>>>> >>>>>>>>> They will return >>>>>>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>>>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>>>>>> >>>>>>>>> If this is the way to go, I will look more into how to implement this. >>>>>>>>> Adapter pattern may be used. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> Jun Han >>>>>>>>> >>>>>>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>>>>>> Hi, Eduard and Fabio, >>>>>>>>>>> >>>>>>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>>>>>> wiki, space. >>>>>>>>>>> Please see the screenshot at >>>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>>>>>> I think it's from an early stage of development. >>>>>>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>>>>>> >>>>>>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>>>>>> other dialog windows related to connection, wiki, space. >>>>>>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>>>>>> heavy lifting is done in the core. >>>>>>>>>> >>>>>>>>>> What I actually wanted to tell you is that you should take the >>>>>>>>>> refactoring in a modular direction and consider your work as a >>>>>>>>>> contribution and alternative for the existing system and not only as a >>>>>>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>>>>>> mechanism that allows you to do so (see our first discussions on >>>>>>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>>>>>> model, etc) as the main think the ui and even core components >>>>>>>>>> communicate with and keep the implementation of that abstraction layer >>>>>>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>>>>>> act accordingly. >>>>>>>>>> >>>>>>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>>>>>> mind at all time during GSoC. >>>>>>>>>> >>>>>>>>>> Besides that, keep up the good work ;) >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Eduard >>>>>>>>>>> Best regards >>>>>>>>>>> Jun Han >>>>>>>>>>> >>>>>>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>> >>>>>>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>>>>>> would show this information in the property panel of the connection. >>>>>>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>>>>>> only >>>>>>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>>>>>> >>>>>>>>>>>> Connection01 >>>>>>>>>>>> - wiki1 >>>>>>>>>>>> -- spaceA >>>>>>>>>>>> --- pageX >>>>>>>>>>>> - wiki2 >>>>>>>>>>>> - etc. >>>>>>>>>>>> >>>>>>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>>>>>> should be displayed in the properties page of a connection. >>>>>>>>>>>> >>>>>>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Eduard >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Fabio >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han&lt;jun.han37(a)gmail.com&gt; >>>>>>>>> wrote: >>>>>>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A screenshot is available at: >>>>>>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>>>>>> >>>>>>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>>>>>> "syntaxes" >>>>>>>>>>>>>> and "wikis" later on. >>>>>>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>>>>>> out, >>>>>>>>>>>>>> I would pick up the pace. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>> Jun Han >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>>>>>> account this into the plugin. >>>>>>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>>>>>> do >>>>>>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>>>>>> ---- Main >>>>>>>>>>>>>>> ------ WebHome >>>>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>>>> ---------- 0 >>>>>>>>>>>>>>> ---------- 1 >>>>>>>>>>>>>>> ---------- 2 >>>>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>>>> ---------- 0 >>>>>>>>>>>>>>> ---------- 1 >>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>>>>>> change >>>>>>>>>>>>>>> to some other IDs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>>>>>> have >>>>>>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>>>>>> easier management of the objects. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>>>>>> class like: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------ WebHome >>>>>>>>>>>>>>> -------- Attachments >>>>>>>>>>>>>>> ---------- dog.png >>>>>>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>>>>> etc. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>>>>>> again the API specs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>>>>>> new >>>>>>>>>>>>>>> stuff. :) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Eduard >>>>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han&lt;jun.han37(a)gmail.com&gt; >>>>>>>>> wrote: >>>>>>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>>>>>> functionality >>>>>>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>>>>>> means >>>>>>>>>>>>>>>>> login fails. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>>>>>> code >>>>>>>>>>>>>>>>> accordingly. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>>>>>> panel, >>>>>>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>>>>>> them? >>>>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Jun Han >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>>>>>> side >>>>>>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>>>>>> token" >>>>>>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>>>>>> so >>>>>>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>>>>>> previously >>>>>>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>>>>>> each request. >>>>>>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>>>>>> cookie by >>>>>>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>>>>>> requests. >>>>>>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>>>>>> OAuth-like >>>>>>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han&lt;jun.han37(a)gmail.com&gt; >>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>>>>>> functionality >>>>>>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>>>>>> something like: >>>>>>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>>>>>> HTTP >>>>>>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>>>>>> the response. >>>>>>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>>>>>> Jun Han

Hi, On Mon, Jun 20, 2011 at 12:05 PM, Vincent Massol&lt;vincent(a)massol.net&gt; wrote: Keep it for now. The maintenance cost is not very high. XOffice still depends on it. Note that REST does not cover the entire XML-RPC functionality yet(iirc it's missing syntax conversion, search, and a few others). Florin _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jun, I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :)) Please take a look. Thanks, Fabio On Sun, Jun 19, 2011 at 4:57 PM, Jun Han&lt;jun.han37(a)gmail.com&gt; wrote: _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Eduard, I think I understand what you and Fabio discussed regarding the model package. My current implementation looks like the following: AbstractXWikiEclipsePage / \ RestPage XmlrpcPage where RestPage wraps jaxb.model.Page and XmlrpcPage wraps xmlrpc.model.Page. This introduces 3 model packages, which is not appropriate. The suggestion from Fabio and you is to remove the redundancy and various DataManager implementation will take care the model details.

For example, it

would manipulate either jaxb.model.Page or xmlrpc.model.Page and returns the XWikiEclipsePage instance.

Best regards Jun Han On 06/22/2011 07:22 AM, Eduard Moraru wrote: https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70… of If to expose to users something purely technical (ie the backend implementation)? should be a "hidden" config param not exposed to users and that we use internally only IMO. users, i.e. they shouldn't have to think when using XEclipse. two very bit faster. wrote: tried XWiki will xwiki.eclipse.core.model AbstractRemoteDataStorage. (dialogs, model AbstractRemoteDataStorage in will well in with a back-end, implementing wrote: correct one. will try this. connection, http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png one and requires finish menu), and since the only as a adding a (interfaces, layer this and reason, that in connection. I connection. leave proposal: version and Admin on the subwiki1 (Admin), it access. names. requests the http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png I plan to continue to content different sorted take into (like we like: user) might pages (that will allow print the XWiki`s object value) remember if we 'implicit' first value) allows. Check display/handle the jun.han37(a)gmail.com&gt; username/password. 401 and replace xmlrpc navigation pages? and how to display client "session web form) a credentials with the subsequent jun.han37(a)gmail.com&gt; of IDataStorage {}. authenticated via header to the parsing methods? _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jun, On Thu, Jun 23, 2011 at 12:14 AM, Jun Han&lt;jun.han37(a)gmail.com&gt; wrote: It's not the DataManager implementations that need to take care of that. DataManager is a final class in the org.xwiki.eclipse.storage plugin that uses remote or local data storages. Each storage plugin implements RemoteXWikiDataStorage, accepts and outputs org.xwiki.eclipse.model entities. it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage Thanks, Eduard I am on the way of re-factoring the code. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jun, On Thu, Jun 23, 2011 at 12:14 AM, Jun Han&lt;jun.han37(a)gmail.com&gt; wrote: It's not the DataManager implementations that need to take care of that. DataManager is a final class in the org.xwiki.eclipse.storage plugin that uses remote or local data storages. Each storage plugin implements RemoteXWikiDataStorage, accepts and outputs org.xwiki.eclipse.model entities. it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage Thanks, Eduard I am on the way of re-factoring the code. _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Dear all, I uploaded a short demo video in youtube to show the current status of XEclipse. The URL is http://youtu.be/TwuNjg1XoUs Now the navigation panel is finished including data connection, and it looks like: data connection |- wiki |- space |- page, |-- attachment |-- comment |-- annotation |-- tag |-- page class

I will continue working on: (1) re-factor xmlrpc backend (2) modify the local storage API and apply a flat structure for the local cached objects. Best regards Jun Han On 06/23/2011 05:55 AM, Eduard Moraru wrote: outputs https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70… wrote: (e.g., used. rest want push feasible. implementation two plugins functions. as comes implement this of I on abstraction keep and xwiki name on to jun.han37(a)gmail.com attribute, little been should something they login while org.xwiki.eclipse.ui the of retrieve some implementation logout _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Hi Jun, On Jul 14, 2011, at 6:14 AM, Jun Han wrote: Wow this is really cool! Well done! I'm now eager to start using XEclipse again :) Is there a version I could test (for my mac)? Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

On Jul 22, 2011, at 6:42 PM, Jun Han wrote: Very cool again! Does it support XWiki Syntax 2.0 content (page creation in 2.0 syntax, syntax coloring)? The demo shows an example with the 1.0 syntax. Thanks -Vincent _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs

Dear all, The demo video is http://youtu.be/QSKSpgvveHU The major part of my recent work is listed as below: 1. page creation, modification, synchronization and deletion 2. page translation creation, modification, synchronization and deletion 3. object creation, modification, synchronization and deletion 4. implement the local storage layer using flat file structure and replace xml serialization/de-serialization with JSON 5. Upgrade tycho from v0.11.1 to v0.13.0-SNAPSHOT, which fixes the issue of not being able to generate macOSX product from linux distro. The current maven build script is tested under Fedora 15 and can generate mac OSX x86_64/x86 products successfully. However, I have not tested the functions of generated RCP application in a mac OSX environment. Some modifications in API and improvements: 1. add and remove tag for a page 2. comment creation and deletion 3. attachment creation, modification and deletion 4. grab space

Best regards Jun Han _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs