Hi Jun, On Thu, Jun 23, 2011 at 12:14 AM, Jun Han <[email protected]> wrote:
> 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. 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. > For > example, it it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage Thanks, Eduard > would manipulate either jaxb.model.Page or xmlrpc.model.Page > and returns the XWikiEclipsePage instance. > I am on the way of re-factoring the code. > > Best regards > > Jun Han > > On 06/22/2011 07:22 AM, Eduard Moraru wrote: > > Hi Jun, > > > > I`m pinging you since I don`t know if you were following the little > > discussion on > > > https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b18fb3715f0d#commitcomment-440786 > > based on Fabio's suggestions. > > > > Out of all the aspects, I think this is the one you should focus on now > > and finish the refactoring so you can proceed with the REST specifics. > > > > Cheers, > > Eduard > > > > On 06/20/2011 08:10 PM, Fabio Mancinelli wrote: > >> 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<[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 > >>> > >> _______________________________________________ > >> devs mailing list > >> [email protected] > >> http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
