25 Jul
2007
25 Jul
'07
7:10 a.m.
Hi Vincent,
On 7/25/07, Vincent Massol <vincent(a)massol.net> wrote:
On Jul 24, 2007, at 9:03 PM, Asiri Rathnayake wrote:
Hi Sergiu,
On 7/25/07, Sergiu Dumitriu <sergiu.dumitriu(a)gmail.com> wrote:
I think this is good. Few urgent questions then,
1. Shall we first finish the work for Xeclipse m1 and then later look into
"refresh" work or do we need this mechanism (as it applies globally) before
doing anything else ? I prefer the first approach :)
2. How can i check whether a certain RPC invocation have admin rights ? (A
simple code sample would be greate!!!)
Thanks.
- Asiri
On 7/24/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
Agreed.
Still, if there's an error while deleting documents, the server method
Hi All,
We were silent for few days due to mid-semester work load (still have
some
unfinished business). Anyway, I have added the
removeSpace RPC to
xwiki
back-end. But now i'm having few doubts about
it. The remove space RPC
works
by retrieving all the page names under the given
space and deleting
them
individually. But following complications may
happen when using this
RPC,
1. If the user does not have enough privileges to delete some of the
pages
within that space, an exception will be thrown
half-way down. Now the
RPC
invoker does not know which pages were removed
and which were not.
(Thus, he
is out of sync with the wiki)
2. If instead we chose to remove page by page from the client -
Xeclipse
(say), we don't have this problem , and we
could even display a
progress
bar. (to indicate that pages are being deleted).
Since the XML RPC API requires the removeSpace() RPC, we must indeed
add it.
But wouldn't it be better if we do not use
this RPC within Xeclipse
(due to
reasons mentioned above) ?
Or, is there a better way to implement removeSpace() RPC ? (like
checking
privileges before doing anything ?) ) (+ How ? )
From the user PoV, it is better to have a feedback as documents are
deleted. This means that the client should make requests one by one.
From a developer PoV, this means a lot more traffic and a lot more
time, as each request creates a new connection, a new context
initialization, new objects, etc. should not be aborted, but should keep a list of
failed documents.
Now, I don't know what to do with this list. Should the method return
a List, and if it is empty then everything was OK? Or should we simply
return true/false, and make another call to see what documents are
left in the space, if the result was "false"?
These are the types of complications that i came across. Although we can
come up with some workaround like making a second call to sync the client
with server, we can avoid all that trouble by simply deleting page by
page. But
again that is little bit (?) more over-head than a single RPC.
I prefer deleting page by page since that would make our life easy by not
having
to worry about complex state management on the client (like making a
second RPC
and refreshing the whole object model on the client so that it corresponds
to server).
You need a refresh button anyway as changes can happen on the server.
Actually I think the strategy should be:
- try an action
- in case of error, refresh and try again
- if it doesn't work, report it
WDYT?
The alternative (which is slightly longer but maybe longer) would be:
- refresh
- try action
- report if error
Thanks
-Vincent
--
You receive this message as a subscriber of the xwiki-dev(a)objectweb.orgmailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws