This leads to a general question: do we want to continue supporting XMLRPC in XWiki, in the platform (now that we have good REST support) or should we drop it and move it as a contrib/retired module? (once we've migrated all our modules to use REST of course. I can think ok xeclipse and some functional tests).
Thanks -Vincent On Jun 20, 2011, at 10:57 AM, Thomas Mortagne wrote: > On Mon, Jun 20, 2011 at 10:48, Vincent Massol <[email protected]> wrote: >> Hi Fabio/Jun, >> >> On Jun 20, 2011, at 10:44 AM, Fabio Mancinelli wrote: >> >>> 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. >> >> We've been supporting REST for a very long time now. My opinion is to drop >> XMLRPC support altogether in the next release of XEclipse. > > 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 <[email protected]> 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<[email protected]> 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<[email protected]> >>>>>>>>> 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<[email protected]> >>>>>>>>>> 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<[email protected]> >>>>>>>>>> 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<[email protected]> >>>>>>>>>> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
