24 Jul
2007
24 Jul
'07
6:13 p.m.
Hi Vincent,
On 7/24/07, Vincent Massol <vincent(a)massol.net> wrote:
Hi Asiri/Tharindu,
On Jul 24, 2007, at 4:33 PM, Asiri Rathnayake wrote:
On 7/24/07, Vincent Massol <vincent(a)massol.net> wrote:
I don't think this is a good idea. But we'll wait for other opinions.
Thanks for your POV but I think we're not talking about the same thing at
all.... :)
I know exceptions are useful in general and I agree with that of course...
I said "IF our goal is to implement the Confluence XMLRPC interface". I
think this is our goal. Why are we doing this? For one reason I can see:
that anyone who has code that interacts with Confluence can use that code to
interact with XWiki. So 2 advantages:
- we don't create yet a new API
- confluence tools can work seamlessly with XWiki
aha... Now I get it. I think we need to verify whether actual Confluence
implementation throws exceptions or not (i beleive they don't since the API
doesn't indicate of such a thing). If that is so, it's better we remove the
Exceptions (so we have more integration). But shouldn't there be any
mechanism to report server errors and such (i'm still scratching my head) ?
Of course that'll work well only if we implement the real confluence API...
Hi,
If our goal is to implement the Confluence XMLRPC interface
(http://confluence.atlassian.com/display/DOC/Remote+API+Specification)
then it seems to me we shouldn't throw XWikiException in any method in our
ConfluenceRpcInterface
interface. Several methods instead should return a boolean to indicate
success or failure.
Does anyone know why we're throwing them?
I believe the reason is that we should be able to indicate to the user
about what went wrong on the server. This is very useful since there may be
situations where the user needs some help with. For an example if the user
enters a wrong password when logging in, the exception says that something
is wrong with logging details (or so it should). Similar situations apply
for other operations as well. But having said that, the current
implementation does not provide much help with error messages, we need to
improve it.
Are we ok to remove all exception throwing?
and that confluence API doesn't throw any
exception AFAIK.
BTW it's funny that you want to keep the exceptions since it's because of
your patch that I'm proposing to remove them... ;) You created a patch that
returns a boolean in addition to throwing an exception. This is obviously
wrong as they serve the same purpose.
Yes, but there the problem was, when the return type is specified as void in
the RPC, the request doesn't even reach the implementation (i couldn't find
out why). I changed it to boolean as a workaround, but still it's not the
right thing.
In conclusion we need to choose:
1) either we want to implement the Confluence API and
we should drop the
exceptions
Should we do something about void return types then ? The API has few
methods that return void, but we have a problem with void return types in
our implementation, think we need to find out why void return types cause a
problem.
2) either we don't want and then we shouldn't call it ConfluenceRpcInterface
and then we can throw exceptions...
I personally like this solution since we can add more features of our own in
the future, but it's always good to support some standard as well.
Thanks for the clear explanation. :)
- Asiri
Hope this makes it more clear,
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