Venkatesh Nandakumar wrote:
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/xwiki...) <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/xwiki-core-xmlrpc-client/apidocs/org/xwiki/xmlrpc/XWikiXmlRpcClient.html#searchAllPagesIds()<http://maven.xwiki.org/site/xwiki-core-parent/xwiki-core-xmlrpc-parent/xwiki-core-xmlrpc-client/apidocs/org/xwiki/xmlrpc/XWikiXmlRpcClient.html#searchAllPagesIds%28%29> 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/