On Jul 25, 2007, at 10:51 AM, Catalin Hritcu wrote:
Hello,
On 7/24/07, Vincent Massol <vincent@massol.net> wrote: [snip]
In conclusion we need to choose: 1) either we want to implement the Confluence API and we should drop the exceptions 2) either we don't want and then we shouldn't call it ConfluenceRpcInterface and then we can throw exceptions... [snip]
I have a couple of questions regarding this.
What are the advantages of really implementing the Confluence API (now we don't really do it!)? Is there anybody who needs to use both? Is there any tool which would be able to use Confluence and XWiki interchangeably? For example will Xeclipse support both Confluence and XWiki?
I see some advantages but not really drawbacks... * They have already fleshed out an API so what's the point of creating a completely different one? Let's benefit from their efforts * Better for our users as it's more likely they'll know the Confluence XMLRPC API rather than some obscure one we invent * We could add APIs to their interface (for XWiki's extended features) without breaking the fact that we implement the Confluence API * I haven't really searched for nice confluence tools using the XMLRPC API but I'm 100% sure we'll gain from this (a pity TimTam is using their SOAP API): - Here are some scripts: http://confluence.atlassian.com/label/ CONFEXT/xml-rpc - http://swizzle.codehaus.org/Swizzle+Confluence. This is really great for us and actually would be a good way to test that we do implement the Confluence API. I can tell you I know people who are going to love it when I break to them that they can use swizzle to control XWiki remotely... ;) But we need to finish our compliance with the Confluence API first. XEclipse will not support Confluence AFAIK and couldn't as we'll need to add XWiki-specific features. I'd be against going away from the Confluence API as I can only see disadvantages right now. We can work around any issue we have with their API and still keep compatibility IMO. Thanks -Vincent