Here's an idea:  Let's define an [XML-RPC] or [SOAP] interface to Wiki.  I don't exactly know what we could do with it, but at least we could do things like:

* Automatical notification of page changes (someone would need to write a script that would check the [RecentChanges], then email anyone.
* Combining Wikis in a manner more efficient than [InterWiki].

This would save us from actually requiring to implement all sorts of features into JSPWiki itself, and allow people to make their own modular thingies.


I'm thinking of the following interfaces:

* __getRecentChanges( long timestamp )__: Get list of changed pages since ''timestamp''.
* __getPage( String pagename, int version )__: Get the raw Wiki text of page.
* __getPageText( String pagename, int version )__: Get page data rendered as plain text, with most of formatting removed (this should be really good for when you actually send wiki pages via email or something).
* __getPageHTML( String pagename, int version )__: Return page in rendered HTML.  This is of course required because you can never know how the [WikiText|TextFormattingRules] should be applied, since it varies from Wiki to Wiki.

I don't know whether writing would be such a good idea.  But with these you could get somewhere anyway.

That's a very interesting thought. It allows any outside process to monitor and  perform actions based on the current state of the Wiki, but without actually affecting the Wiki.

As specified above, the only way to get a list of pages is __getRecentChanges()__. It seems a bit limiting to think that all the other process would care about is recently changed files. What about:
*__getAllPages()__: Get list of all Wiki pages.
*__getMatchingPages(String query)__: Get list of all Wiki pages that match the query. Of course, this then begs the question of what matching means. That's kind of annoying.

getMatchingPages() may be overkill. Perhaps these queries would be better implemented with a SOAPProvider, a WikiPageProvider based on SOAP. Then the matching SOAP service can store the files anyway it likes, be notified the instant that a page is stored, and query the page text any silly way it feels like. A SOAPProvider would also get around the limitation that the API specified above requires the interested party to "poll" the WikiEngine periodically. With a SOAPProvider, if you care about every save or read, you can track them yourself.