12 Jun
2009
12 Jun
'09
1:28 p.m.
Hi,
XWiki has evolved a lot in the past year and new client apps were created.
Our current Xml-Rpc API is aligned to the Confluence 1.0 API
specification and hasn't been really enriched in a long time.
Since we have some distinct features like 'polyglot wiki' I propose to
create a new "xwiki2" method set to handle XWiki 2.0 method calls.
The new handler will be added to the Apache Xml-Rpc servlet properties file.
Proposed new xml-rpc methods(mostly needed for XEclipse, XOffice and XOO):
- parseFromHtml(String html, String syntax) : String
- render(String source, String syntaxId) : String
- cleanHtml(String dirtyHtml) : String
- add class ( http://jira.xwiki.org/jira/browse/XWIKI-3499 )
- getConfiguredSyntaxes
- getVirtualWikisNames
- getMacros, etc.
Proposed Xml-Rpc model extensions:
- Page
- syntaxId;
- ServerInfo/Wiki:
- isMultiWiki
- defaultSyntax
- encoding
WDYT?
Thanks,
Florin Ciubotaru
12 Jun
12 Jun
2:29 p.m.
Florin Ciubotaru wrote:
Hi,
XWiki has evolved a lot in the past year and new client apps were created.
Our current Xml-Rpc API is aligned to the Confluence 1.0 API
specification and hasn't been really enriched in a long time.
Since we have some distinct features like 'polyglot wiki' I propose to
create a new "xwiki2" method set to handle XWiki 2.0 method calls.
The new handler will be added to the Apache Xml-Rpc servlet properties file.
Proposed new xml-rpc methods(mostly needed for XEclipse, XOffice and XOO):
- parseFromHtml(String html, String syntax) : String
- render(String source, String syntaxId) : String
- cleanHtml(String dirtyHtml) : String
- add class ( http://jira.xwiki.org/jira/browse/XWIKI-3499 )
- getConfiguredSyntaxes
getEnabledSyntaxes sounds better to me
- getVirtualWikisNames
- getMacros, etc.
Proposed Xml-Rpc model extensions:
- Page
- syntaxId;
- defaultEditMode?
- editComment?
- hidden?
- ServerInfo/Wiki:
- isMultiWiki
- defaultSyntax
- encoding
WDYT?
+1
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
2:42 p.m.
On Jun 12, 2009, at 2:29 PM, Sergiu Dumitriu wrote:
Florin Ciubotaru wrote:
He's using the same name as in the XWiki API which is good IMO. If we
want getEnabledSyntaxes the we also need to change the API.
Enabled or Active are better I agree since even though they are
configured they can still be deactivated at runtime by unregistering a
parser. Also it's possible to dynamically add a new parser even if
it's not configured.
+1 in general. Just make sure that the XWiki XMLRPC client continues
to work for accessing Confluence instances.
Thanks
-Vincent
Hi,
XWiki has evolved a lot in the past year and new client apps were
created.
Our current Xml-Rpc API is aligned to the Confluence 1.0 API
specification and hasn't been really enriched in a long time.
Since we have some distinct features like 'polyglot wiki' I propose
to
create a new "xwiki2" method set to handle XWiki 2.0 method calls.
The new handler will be added to the Apache Xml-Rpc servlet
properties file.
Proposed new xml-rpc methods(mostly needed for XEclipse, XOffice
and XOO):
- parseFromHtml(String html, String syntax) : String
- render(String source, String syntaxId) : String
- cleanHtml(String dirtyHtml) : String
- add class ( http://jira.xwiki.org/jira/browse/XWIKI-3499 )
- getConfiguredSyntaxes
getEnabledSyntaxes sounds better to me -
getVirtualWikisNames
- getMacros, etc.
Proposed Xml-Rpc model extensions:
- Page
- syntaxId;
- defaultEditMode?
- editComment?
- hidden?
- ServerInfo/Wiki:
- isMultiWiki
- defaultSyntax
- encoding
WDYT?
+1
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
2:36 p.m.
Hi Florin,
Florin Ciubotaru wrote:
Hi,
XWiki has evolved a lot in the past year and new client apps were created.
Our current Xml-Rpc API is aligned to the Confluence 1.0 API
specification and hasn't been really enriched in a long time.
Since we have some distinct features like 'polyglot wiki' I propose to
create a new "xwiki2" method set to handle XWiki 2.0 method calls.
The new handler will be added to the Apache Xml-Rpc servlet properties file.
+1
Proposed new xml-rpc methods(mostly needed for XEclipse, XOffice and XOO):
- parseFromHtml(String html, String syntax) : String
- render(String source, String syntaxId) : String
I'm not sure about the name of these methods. "parseFromHtml" does parse
the input HTML into XDOM but also renders the XDOM into the specified
syntax. "render" uses the (X)HTML renderer but also needs a syntax
specific parser. Moreover why are you restricting the API to HTML? Some
clients might know other syntaxes. I think it's better to have a generic
convert(text, fromSyntax, toSyntax) method.
- cleanHtml(String dirtyHtml) : String
- add class ( http://jira.xwiki.org/jira/browse/XWIKI-3499 )
- getConfiguredSyntaxes
- getVirtualWikisNames
- getMacros, etc.
Proposed Xml-Rpc model extensions:
- Page
- syntaxId;
- ServerInfo/Wiki:
- isMultiWiki
- defaultSyntax
- encoding
WDYT?
Sounds good overall, +1
Thanks,
Marius
Thanks,
Florin Ciubotaru
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:39 p.m.
On 06/12/2009 02:28 PM, Florin Ciubotaru wrote:
Hi,
XWiki has evolved a lot in the past year and new client apps were created.
Our current Xml-Rpc API is aligned to the Confluence 1.0 API
specification and hasn't been really enriched in a long time.
Since we have some distinct features like 'polyglot wiki' I propose to
create a new "xwiki2" method set to handle XWiki 2.0 method calls.
The new handler will be added to the Apache Xml-Rpc servlet properties file.
Proposed new xml-rpc methods(mostly needed for XEclipse, XOffice and XOO):
- parseFromHtml(String html, String syntax) : String
- render(String source, String syntaxId) : String
You'll need a context to do this right, the document for which the source must
be rendered (because you'll have relative references to images, links, etc in
the content, or macros which may require a complete context to be rendered
properly). Either you get it somehow on the server (which I don't see how can be
done) or you'll need to add it in the service interface.
Happy coding,
Anca
- cleanHtml(String dirtyHtml) : String
- add class ( http://jira.xwiki.org/jira/browse/XWIKI-3499 )
- getConfiguredSyntaxes
- getVirtualWikisNames
- getMacros, etc.
Proposed Xml-Rpc model extensions:
- Page
- syntaxId;
- ServerInfo/Wiki:
- isMultiWiki
- defaultSyntax
- encoding
WDYT?
Thanks,
Florin Ciubotaru
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:54 p.m.
Anca Paula Luca wrote:
On 06/12/2009 02:28 PM, Florin Ciubotaru wrote:
Right, there will be an additional pageId: String or page: Page parameter.
Hi,
XWiki has evolved a lot in the past year and new client apps were created.
Our current Xml-Rpc API is aligned to the Confluence 1.0 API
specification and hasn't been really enriched in a long time.
Since we have some distinct features like 'polyglot wiki' I propose to
create a new "xwiki2" method set to handle XWiki 2.0 method calls.
The new handler will be added to the Apache Xml-Rpc servlet properties file.
Proposed new xml-rpc methods(mostly needed for XEclipse, XOffice and XOO):
- parseFromHtml(String html, String syntax) : String
- render(String source, String syntaxId) : String
You'll need a context to do this right, the document for which the source must
be rendered (because you'll have relative references to images, links, etc in
the content, or macros which may require a complete context to be rendered
properly). Either you get it somehow on the server (which I don't see how can be
done) or you'll need to add it in the service interface.
Happy coding,
Anca
- cleanHtml(String dirtyHtml) : String
- add class ( http://jira.xwiki.org/jira/browse/XWIKI-3499 )
- getConfiguredSyntaxes
- getVirtualWikisNames
- getMacros, etc.
Proposed Xml-Rpc model extensions:
- Page
- syntaxId;
- ServerInfo/Wiki:
- isMultiWiki
- defaultSyntax
- encoding
WDYT?
Thanks,
Florin Ciubotaru
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
16 Jun
16 Jun
2:41 p.m.
On Jun 12, 2009, at 1:28 PM, Florin Ciubotaru wrote:
Hi,
XWiki has evolved a lot in the past year and new client apps were
created.
Our current Xml-Rpc API is aligned to the Confluence 1.0 API
specification and hasn't been really enriched in a long time.
Since we have some distinct features like 'polyglot wiki' I propose to
create a new "xwiki2" method set to handle XWiki 2.0 method calls.
The new handler will be added to the Apache Xml-Rpc servlet
properties file.
Proposed new xml-rpc methods(mostly needed for XEclipse, XOffice and
XOO):
- parseFromHtml(String html, String syntax) : String
- render(String source, String syntaxId) : String
- cleanHtml(String dirtyHtml) : String
- add class ( http://jira.xwiki.org/jira/browse/XWIKI-3499 )
- getConfiguredSyntaxes
- getVirtualWikisNames
- getMacros, etc.
Proposed Xml-Rpc model extensions:
- Page
- syntaxId;
- ServerInfo/Wiki:
- isMultiWiki
- defaultSyntax
- encoding
WDYT?
Sorry for the late reply but I was on leave.
+1 in general.
We should also add methods for
1) Getting collections (i.e., pages/spaces/objects/attachments/etc)
using start and offset parameters. This is needed for pagination and
incremental retrieval of huge amount of data (e.g., a wiki with
thousands of spaces and pages)
2) Maybe we can use the new "xwiki2" endpoint in order to provide a
cleaner and more xwiki-oriented API. I was thinking, in particular, to
the semantic mismatches between Confluence (which uses integer IDs for
pages) and XWiki (which uses semantic rich IDs like Space.Name) and
the "rename" compatibility that makes impossible, right now, to simply
change the title of an XWiki page without actually renaming the page.
2bis) If we want to keep it as it is (i.e., confluence semantics) we
need a method for changing the title of a page without renaming it.
-Fabio
28 Jun
28 Jun
4:01 p.m.
Hi all,
I would also like to have a
-moveAttachment() according to
http://confluence.atlassian.com/display/DOC/Remote+API+Specification#Remote…
uses copyAttachment() and removeAttachment() internally.
Other xmlrpc functions, (non-confluence specified), that should be there
are:-
-copyAttachment()
-copyPage()
-movePage() [current renamePage() being used by XEclipse is not good]
2009/6/16 Fabio Mancinelli <fabio.mancinelli(a)xwiki.com>
1) Getting collections (i.e.,
pages/spaces/objects/attachments/etc)
using start and offset parameters. This is needed for pagination and
incremental retrieval of huge amount of data (e.g., a wiki with
thousands of spaces and pages)
The 2nd patch in xwiki-1559 does this, albeit only for pages, enough to
rectify xeclipse-106. And it uses native SQL, and not parametrized query,
as told to me by sergiu.
I will create the xmlrpc functions that I said above and will notify Florin.
The functions would be used for Drag and Drop Functionalities for XEclipse
navigator. http://gsoc.myxwiki.org/xwiki/bin/view/XEclipse/DragDrop
Current status of the gsoc project:-
http://gsoc.myxwiki.org/xwiki/bin/view/XEclipse/
Please let me know.
Venkatesh Nandakumar
Department of Electronics & Computer Engineering
Indian Institute of Technology Roorkee
5612
days inactive
5628
days old
7 comments
7 participants
participants (7)
-
Anca Paula Luca -
Fabio Mancinelli -
Florin Ciubotaru -
Marius Dumitru Florea -
Sergiu Dumitriu -
Venkatesh Nandakumar -
Vincent Massol