Hi, On Mon, Jun 20, 2011 at 12:05 PM, Vincent Massol <[email protected]> wrote:
> 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). 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 > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
