On Jul 25, 2007, at 10:51 AM, Catalin Hritcu wrote:
Hello,
On 7/24/07, Vincent Massol <vincent(a)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