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
