The most obvious WikiClient is a web browser that talks HTTP to a WikiServer and renders the HTML given to it from the server.
Unfortunately, most web browsers are difficult to extend. Even web browsers that support client-side scripting solutions such as JavaScript still require that the actual script comes from the server.
This isn't necessarily so. For example, I have a multitude of BookMarklet?s stored in my favourites bar, letting me do interesting things to foreign pages. At first I thought that the length limit might be a problem, until I realised a bookmarklet can insert html into a page, including a <SCRIPT src="url-to-my-javascript"></SCRIPT>. Problem solved, infinite possibilities for javascript.
This is a good idea. It would still be nice to allow client-side languages other than javascript.
Alternatively, all the server has to do is to allow a user preference of specifying the url for a javascript link. I have a working solution on my testbed server which inserts a LinkBasket? onto the page, and inserts LinkIcon?s in front of all WikiPageLink?s. Send me an email, I'll send you the URL to the testbed server '' -- EricScheid
Do you have any options to just send just raw page data along with a LinkBasket??
There's an XmlRpc interface on wikis in the works if anyone's interested. --LesOrchard
WikiPage could be sent with specific MIME Type. Browsers could either use plugin to display this page or save file to disk and open it with preconfigured application that feeds processed data back to browser (which would be seamless action if browser is configured carefully).
I see a problem with bookmarklet - browser may display wikitext as text/plain and not allow any HTML. Besides bookmarklet is not an automatic solution.