24 Jul
2007
24 Jul
'07
11:42 a.m.
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 ? )
Thanks a lot.
Best Regards,
- Asiri
24 Jul
24 Jul
8:48 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
On 7/24/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
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.
Still, if there's an error while deleting documents, the server method
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"?
Sergiu
--
http://purl.org/net/sergiu
9:03 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
Hi Sergiu,
On 7/25/07, Sergiu Dumitriu <sergiu.dumitriu(a)gmail.com> wrote:
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).
Thanks.
- Asiri
Sergiu
--
http://purl.org/net/sergiu
--
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
10:12 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
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:
On 7/24/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
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
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.
Agreed.
Still, if there's an error while deleting documents, the server method
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).
25 Jul
25 Jul
7:10 a.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
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
10:36 a.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
Hi Asiri,
On Jul 25, 2007, at 7:10 AM, Asiri Rathnayake wrote:
Hi Vincent,
On 7/25/07, Vincent Massol <vincent(a)massol.net> wrote:
On Jul 24, 2007, at 9:03 PM, Asiri Rathnayake wrote:
Actually I think it's not so good. It's too dangerous. Also we
shouldn't delete a space if someone has added a page to it. I prefer
the following approach:
* Before any modification (delete, edit, rename, etc) we first do a
refresh and check if there has been no modification. If there has
been we cancel the action and ask the user to review the changes
before doing anything.
For example for the remove Space this means:
- check if any page was modified since last refresh
- check if any page was removed or added since last refresh
- if so, tell what was changed to the user and ask him to review the
changes before hitting the delete button again
- refresh the workspace with the changes
The only tricky part is when the user has modified content locally
and it has also been modified remotely. Then we need to open a page
showing a diff between the two versions (using Eclipse diff/merge
components) and asking the user to do the merge.
Hi Sergiu,
On 7/25/07, Sergiu Dumitriu <sergiu.dumitriu(a)gmail.com> wrote:
On 7/24/07, Asiri Rathnayake <asiri.rathnayake(a)gmail.com> wrote:
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
I think this is good. Few urgent questions then, 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.
Agreed.
Still, if there's an error while deleting documents, the server
method
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).
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 :)
You need to release 1.0M1 first. This is the priority.
2. How can i check whether a certain RPC invocation have admin
rights ? (A simple code sample would be greate!!!)
You don't check, you simply know it... :)
Meaning if the user wants to remove a space you first check if he has
admin rights (do we have an API for this? If not we should probably
add it) and if so calls the removeSpace method.
Thanks
-Vincent
WDYT?
The alternative (which is slightly longer but maybe longer) would be:
- refresh
- try action
- report if error
Thanks
-Vincent
2:34 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
Hi Vincent,
On 7/25/07, Vincent Massol <vincent(a)massol.net> wrote:
Hi Asiri,
On Jul 25, 2007, at 7:10 AM, Asiri Rathnayake wrote:
Hi Vincent,
On 7/25/07, Vincent Massol <vincent(a)massol.net> wrote:
Looks ok to me. :)
1. Shall we first finish the work for Xeclipse m1 and then later look into
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,
Actually I think it's not so good. It's too dangerous. Also we shouldn't
delete a space if someone has added a page to it. I prefer the following
approach:
* Before any modification (delete, edit, rename, etc) we first do a
refresh and check if there has been no modification. If there has been we
cancel the action and ask the user to review the changes before doing
anything.
For example for the remove Space this means:
- check if any page was modified since last refresh
- check if any page was removed or added since last refresh
- if so, tell what was changed to the user and ask him to review the
changes before hitting the delete button again
- refresh the workspace with the changes
The only tricky part is when the user has modified content locally and it
has also been modified remotely. Then we need to open a page showing a diff
between the two versions (using Eclipse diff/merge components) and asking
the user to do the merge.
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
"refresh" work or do we need this mechanism
(as it applies globally) before
doing anything else ? I prefer the first approach :)
You need to release 1.0M1 first. This is the priority.
Happy to hear this. :)
2. How can i check whether a certain RPC invocation have admin rights ? (A
simple code sample would be greate!!!)
You don't check, you simply know it... :)
Meaning if the user wants to remove a space you first check if he has
admin rights (do we have an API for this? If not we should probably add it)
and if so calls the removeSpace method.
Confluence API has a lot of methods for such tasks (in security section),
but non of them are implemented (not even mentioned) in our implementation.
so, we'll have to work on it.
Thanks.
- Asiri
Thanks
-Vincent
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
4 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
On Jul 25, 2007, at 2:34 PM, Asiri Rathnayake wrote:
[snip]
Hmm... I wonder if we'll be able to implement fully the Confluence
spec. This will be a good test. For example:
Vector getPermissions(String token, String spaceKey) - Returns a
Vector of Strings representing the permissions the current user has
for this space (a list of "view", "modify", "comment" and /
or "admin").
This means that we need to support the confluence "token"s if we want
XMLRPC client tools to work seamlessly with XWiki. Which means we
need a good mapping between Confluence permissions and XWiki
permissions.
So it means we need to support calling: getPermissions("modify") and
getPermissions("edit") both need to work.
-Vincent
2. How can i
check whether a certain RPC invocation have admin
rights ? (A simple code sample would be greate!!!)
You don't check, you simply know it... :)
Meaning if the user wants to remove a space you first check if he
has admin rights (do we have an API for this? If not we should
probably add it) and if so calls the removeSpace method.
Confluence API has a lot of methods for such tasks (in security
section), but non of them are implemented (not even mentioned) in
our implementation. so, we'll have to work on it.
5:13 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
On 7/25/07, Vincent Massol <vincent(a)massol.net> wrote:
On Jul 25, 2007, at 2:34 PM, Asiri Rathnayake wrote:
[snip]
2. How can i check whether a certain RPC invocation have admin rights ?
I'll be happy to work on this when we're done with XEclipse :)
Thanks.
- Asiri
-Vincent
(A simple code sample would be greate!!!)
You don't check, you simply know it... :)
Meaning if the user wants to remove a space you first check if he has
admin rights (do we have an API for this? If not we should probably add it)
and if so calls the removeSpace method.
Confluence API has a lot of methods for such tasks (in security section),
but non of them are implemented (not even mentioned) in our implementation.
so, we'll have to work on it.
Hmm... I wonder if we'll be able to implement fully the Confluence spec.
This will be a good test. For example:
Vector getPermissions(String token, String spaceKey) - Returns a Vector of
Strings representing the permissions the current user has for this space (a
list of "view", "modify", "comment" and / or
"admin").
This means that we need to support the confluence "token"s if we want
XMLRPC client tools to work seamlessly with XWiki. Which means we need a
good mapping between Confluence permissions and XWiki permissions.
So it means we need to support calling: getPermissions("modify") and
getPermissions("edit") both need to work.
--
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
2:53 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
Hi Vincent,
it seems like confluence methods does throw exceptions,
I referred to comments at the bottom of
API<http://confluence.atlassian.com/display/DOC/Remote+API+Specification…
and found this.
Will look into this more thoroughly later.
- Asiri
On 7/25/07, Vincent Massol <vincent(a)massol.net> wrote:
Hi Asiri,
On Jul 25, 2007, at 7:10 AM, Asiri Rathnayake wrote:
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,
Actually I think it's not so good. It's too dangerous. Also we shouldn't
delete a space if someone has added a page to it. I prefer the following
approach:
* Before any modification (delete, edit, rename, etc) we first do a
refresh and check if there has been no modification. If there has been we
cancel the action and ask the user to review the changes before doing
anything.
For example for the remove Space this means:
- check if any page was modified since last refresh
- check if any page was removed or added since last refresh
- if so, tell what was changed to the user and ask him to review the
changes before hitting the delete button again
- refresh the workspace with the changes
The only tricky part is when the user has modified content locally and it
has also been modified remotely. Then we need to open a page showing a diff
between the two versions (using Eclipse diff/merge components) and asking
the user to do the merge.
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 :)
You need to release 1.0M1 first. This is the priority.
2. How can i check whether a certain RPC invocation have admin rights ?
(A simple code sample would be greate!!!)
You don't check, you simply know it... :)
Meaning if the user wants to remove a space you first check if he has
admin rights (do we have an API for this? If not we should probably add it)
and if so calls the removeSpace method.
Thanks
-Vincent
WDYT?
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
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
4:18 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
On Jul 25, 2007, at 2:53 PM, Asiri Rathnayake wrote:
Hi Vincent,
it seems like confluence methods does throw exceptions,
I referred to comments at the bottom of API spec and found this.
Will look into this more thoroughly later.
Anyway the XMLRPC doesn't support exceptions... :)
Some tools like Apache XMLRPC support vendor extensions like
exceptions but we cannot rely on this of course.
We need to know what Confluence returns when there's an exception and
how tools like swizzle handle that.
Thanks
-Vincent
On 7/25/07, Vincent Massol <vincent(a)massol.net >
wrote:
Hi Asiri,
On Jul 25, 2007, at 7:10 AM, Asiri Rathnayake wrote:
Hi Vincent,
On 7/25/07, Vincent Massol < vincent(a)massol.net> wrote:
On Jul 24, 2007, at 9:03 PM, Asiri Rathnayake wrote:
Actually I think it's not so good. It's too dangerous. Also we
shouldn't delete a space if someone has added a page to it. I
prefer the following approach:
* Before any modification (delete, edit, rename, etc) we first do a
refresh and check if there has been no modification. If there has
been we cancel the action and ask the user to review the changes
before doing anything.
For example for the remove Space this means:
- check if any page was modified since last refresh
- check if any page was removed or added since last refresh
- if so, tell what was changed to the user and ask him to review
the changes before hitting the delete button again
- refresh the workspace with the changes
The only tricky part is when the user has modified content locally
and it has also been modified remotely. Then we need to open a page
showing a diff between the two versions (using Eclipse diff/merge
components) and asking the user to do the merge.
Hi Sergiu,
On 7/25/07, Sergiu Dumitriu < sergiu.dumitriu(a)gmail.com> wrote:
On 7/24/07, Asiri Rathnayake < asiri.rathnayake(a)gmail.com> wrote:
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
I think this is good. Few urgent questions then, 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.
Agreed.
Still, if there's an error while deleting documents, the server
method
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).
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 :)
You need to release 1.0M1 first. This is the priority.
2. How can i check whether a certain RPC invocation have admin
rights ? (A simple code sample would be greate!!!)
You don't check, you simply know it... :)
Meaning if the user wants to remove a space you first check if he
has admin rights (do we have an API for this? If not we should
probably add it) and if so calls the removeSpace method.
Thanks
-Vincent
WDYT?
The alternative (which is slightly longer but maybe longer) would be:
- refresh
- try action
- report if error
Thanks
-Vincent
4:51 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
Hi Vincent,
On 7/25/07, Vincent Massol <vincent(a)massol.net> wrote:
On Jul 25, 2007, at 2:53 PM, Asiri Rathnayake wrote:
Hi Vincent,
it seems like confluence methods does throw exceptions,
I referred to comments at the bottom of
API<http://confluence.atlassian.com/display/DOC/Remote+API+Specification… and
found this.
Will look into this more thoroughly later.
Anyway the XMLRPC doesn't support exceptions... :)
Some tools like Apache XMLRPC support vendor extensions like exceptions
but we cannot rely on this of course.
We need to know what Confluence returns when there's an exception and how
tools like swizzle handle that.
Indeed, this should be our main goal, seamless integration with existing
tools that make use of Confluence API.
Thanks.
- Asiri
Thanks
-Vincent
On 7/25/07, Vincent Massol <vincent(a)massol.net > wrote:
Hi Asiri,
On Jul 25, 2007, at 7:10 AM, Asiri Rathnayake wrote:
Hi Vincent,
On 7/25/07, Vincent Massol < vincent(a)massol.net> wrote:
--
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
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,
Actually I think it's not so good. It's too dangerous. Also we shouldn't
delete a space if someone has added a page to it. I prefer the following
approach:
* Before any modification (delete, edit, rename, etc) we first do a
refresh and check if there has been no modification. If there has been we
cancel the action and ask the user to review the changes before doing
anything.
For example for the remove Space this means:
- check if any page was modified since last refresh
- check if any page was removed or added since last refresh
- if so, tell what was changed to the user and ask him to review the
changes before hitting the delete button again
- refresh the workspace with the changes
The only tricky part is when the user has modified content locally and
it has also been modified remotely. Then we need to open a page showing a
diff between the two versions (using Eclipse diff/merge components) and
asking the user to do the merge.
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 :)
You need to release 1.0M1 first. This is the priority.
2. How can i check whether a certain RPC invocation have admin rights ?
(A simple code sample would be greate!!!)
You don't check, you simply know it... :)
Meaning if the user wants to remove a space you first check if he has
admin rights (do we have an API for this? If not we should probably add it)
and if so calls the removeSpace method.
Thanks
-Vincent
WDYT?
On 7/24/07, Asiri Rathnayake < asiri.rathnayake(a)gmail.com> wrote:
> 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.
Agreed.
Still, if there's an error while deleting documents, the server method
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
The alternative (which is slightly longer but maybe longer) would be:
- refresh
- try action
- report if error
Thanks
-Vincent
24 Jul
24 Jul
9:10 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
On Jul 24, 2007, at 8:48 PM, Sergiu Dumitriu wrote:
On 7/24/07, Asiri Rathnayake
<asiri.rathnayake(a)gmail.com> wrote:
One easy answer: let's follow what the Confluence RPC Interface says.
It says:
Boolean removeSpace(String token, String spaceKey)
(I think "Boolean" is a mistake and should be boolean but that needs
to be checked).
Note: I'm talking about our CongluenceRpc* classes. Not about other
XMLRPC interfaces.
-Vincent
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.
Still, if there's an error while deleting documents, the server method
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"?
9:12 p.m.
New subject: [xwiki-dev] removeSpace RPC & Xeclipse
I think we should mandate Admin rights to executing removeSpace() and
return false otherwise.
We need to check how confluence does it to return more information as
it's indeed not much explanation for the end user.
Thanks
-Vincent
On Jul 24, 2007, at 9:10 PM, Vincent Massol wrote:
On Jul 24, 2007, at 8:48 PM, Sergiu Dumitriu wrote:
On 7/24/07, Asiri Rathnayake
<asiri.rathnayake(a)gmail.com> wrote:
One easy answer: let's follow what the Confluence RPC Interface
says. It says:
Boolean removeSpace(String token, String spaceKey)
(I think "Boolean" is a mistake and should be boolean but that
needs to be checked).
Note: I'm talking about our CongluenceRpc* classes. Not about other
XMLRPC interfaces.
-Vincent 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.
Still, if there's an error while deleting documents, the server
method
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"?
6360
days inactive
6361
days old
13 comments
3 participants
participants (3)
-
Asiri Rathnayake -
Sergiu Dumitriu -
Vincent Massol