Hi Jun, sorry for the "radio-silence"... though Eduard did a great Job answering your questions (thanks Edy :)) Very very good job so far!
I'll send you some more detailed comments asap. Keep up the good work! -Fabio On Wed, Jul 6, 2011 at 5:47 AM, Jun Han <[email protected]> wrote: > 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: >> 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 > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
