20 Jun
2011
20 Jun
'11
11:54 a.m.
Hi,
+1 for hiding the back-end choice, either trough an Advanced section, or
to be determined from the URI.
For dropping XMLRPC from XEclipse, I`d say we should drop it as soon as
XE drops it. It's no trouble to return null or a default value for a
method that is not supported by XMLRPC.
For dropping XMLRPC from XE/platform, +1 as long as it's viable (new
services to implement in REST, XOffice refactoring, etc.) :)
Jun, as far as I have scanned your commits, good job on the refactoring
:) I don`t necessarily like the hardcoded (static instead of dynamic --
discoverable) types of storages, but that's not the main problem right now.
Start replacing that UnsupportedOperationException for the REST storage
with some code ;)
Cheers,
Eduard
On 06/20/2011 12:30 PM, Florin Ciubotaru wrote:
Hi,
On Mon, Jun 20, 2011 at 12:05 PM, Vincent Massol<vincent(a)massol.net> 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:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On Mon, Jun 20, 2011 at 10:48, Vincent
Massol<vincent(a)massol.net>
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<jun.han37(a)gmail.com> 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<jun.han37(a)gmail.com>
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<jun.han37(a)gmail.com>
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<
jun.han37(a)gmail.com>
>>>>>>>>> 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<
jun.han37(a)gmail.com>
>>>>>>>>> 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<
jun.han37(a)gmail.com>
>>>>>>>>>
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs