10 Apr
2009
10 Apr
'09
2:32 a.m.
Sergiu Dumitriu wrote:
Venkatesh Nandakumar wrote:
Oh, looks like I forgot the link:
http://confluence.atlassian.com/display/DOC/Remote+API+Specification#Remote…
Hi devs,
I was discussing with Sergiu, relating to
http://jira.xwiki.org/jira/browse/XECLIPSE-106
The bug is that when XEclipse is connected to a large wiki, of the
order of
5000+ pages, and when ContentAssist is triggered from the editor (using
Ctrl+Space, with cursor inside [] tag), it enters a very large loop, and
hence is very slow.
I found out that :-
1)
http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core-xmlrpc-parent/xwik…
<http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core-xmlrpc-parent/xwiki-core-xmlrpc-client/apidocs/org/xwiki/xmlrpc/XWikiXmlRpcClient.html#search%28java.lang.String,%20java.lang.Integer%29>
Searches for the the content as well as page id. Therefore, as
XWikiXmlRpcClient.search("WebHome", 10) returns :-
Blog.WebHome
Main.RssFeeds
Main.WebHome
Panels.PanelWizard
Panels.WebHome ... etc
which is not what I require.
2)
http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core-xmlrpc-parent/xwik…
is being used in the current implementation(1.4+). This first fetches all
the PageIds of the wiki. And then, on the client's end, XEclipse searches
for the match with String.startsWith
For XWiki Versions less than 1.4, there is a nested for-loop
implementation
using getSpaces() and getPages(), which is even worse.
This is very slow, and large amount of data transfer is required over the
network.
So, with the backing of Sergiu and Florin :), I propose a new XML-RPC
function
List<SearchResult> searchRegexPageId(String regex, Integer maxResults,
Boolean includeContent)
The function is pretty much self-explanatory, with only the PageId's that
match regex are being returned, and includeContent checks if Content
is to
be included for the search.
I really don't know if this function would be of use anywhere else but
for
this application. It would be good to know.
I don't quite like this approach. The XWiki XmlRpc API is based on an
early version of the Confluence API, after which both evolved according
to the needs and features of the two platforms. Looking at the latest
API reference from Confluence, I see that they added a second search
method, one that also accepts a map of parameters. A better and more useful approach is to add this
parameterized search,
since a Map is easy extensible (i.e. any keys can be used). We could
have as parameters, for a start:
- spaceKey; useful for autocompletion after writing the space and the .
- type; useful for searching attachments
- modified; useful for searching recent documents
- searchedField; for what you need, a 'title' would be enough, but this
should be a set, with values from {title, content, objects, attachment,
tags, creator, author, contributor} and maybe others
- startIndex; the index of the first returned result
- maxResults; if we want to comply with the confluence API, this
wouldn't be necessary, since a maxResults parameter is mandatory in the
method signature.
This would be a bit harder to fully implement, but we can start with
minimal features (to have just enough for you to fix XECLIPSE-106) and
add more on the way.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/