This question about Developing extensions (plugins skins etc.): Asked
Best way to support remote CLI via REST / SOAP etc
Has anyone looked at supporting something like this
MediaWiki command-line client but for Foswiki? The idea is to provide a command like
mvs login
to authenticate then
mvs update Myweb.Mytopic
to 'check out' the topic (you can do another
mvs update
to merge changes, like
svn up
), then
mvs commit Myweb.Mytopic
.
This works reasonably well for
MediaWiki, with some minor patches/tweaks. My main question is which existing core API or perhaps plugin is suitable to grab the whole text of a topic and then put the whole thing back later, without using browser - hence SOAP, REST or even XML-RPC would work. Possibly some plugin already provides suitable REST functions.
-- 15 Sep 2010 - 15:36:30 -
RichardDonkin
Well, we've got a
SoapPlugin as well as an
XmlRpcContrib. Alas, both haven't got a full foswiki API, like for example comparable to Confluence's rather complete WSDL. SoapPlugin was actually written to support a Client to connect to other services. Adding a Server makes a lot of sense ... and work.
--
MichaelDaum - 15 Sep 2010
WebDAV is the obvious way to do this.
--
CrawfordCurrie - 15 Sep 2010
I was thinking of something very simple already provided by the Foswiki core or an existing plugin, which should be FOSS though I didn't specify that - so I don't think WebDAV or extending
SoapPlugin is really suitable for me anyway.
Doesn't TinyMCE use a simple AJAX API to retrieve and store a topic using XML over HTTP? Really what I need is something that uses the same protocol/API as this - shouldn't be too hard to port the
CPAN:WWW::Mediawiki::Client code to this.
The retrieve part is taken care of - just use
http://foswiki.org/Support/Question648?raw=text - now I just need the equivalent Save operation for use in the POST - presumably the
save
script would work, but what's the simplest possible POST operation I could do?
--
RichardDonkin - 16 Sep 2010
Looking at what it
use
the MediaWiki Client seems to emulate a browser from the command line so cookies are available etc. The
HijaxPlugin allows Foswiki actions to be used via REST (not attach though). You just need to add
cover=ajax
as a url parameter and the foswiki server starts answering in JSON with content clearly identified in the JSON object. All error responses are also handled. The only problem with this approach comes when strikeone is in play and you POST the /bin/save/... . The plugin comes with
hijax.js
that handles doing a save without a valid key so you'd have to reproduce (the relevant part of) this and
strikeone.js
in Perl but that shouldn't be tricky. The simplest POST would just require a
text
parameter to the standard save url. The alternative would be to write a little plugin with a rest handler for this purpose. You can still add
cover=ajax
and any thrown exceptions would be returned as JSON which could be parsed and presented to the user.
--
DavidPatterson - 16 Sep 2010
This is really important work as
MichaelDaum already pointed out. Personally the applications for which I've had to use SOAP thus far, didn't really have a good reason to justify the pain (and I do find it outrageously painful
So, I have been considering exposing Foswiki as an AtomPub service, but the "easiest" route I think is doing a plugin that provides rationalised, logical HTTP REST API to Foswiki that could be published with WSDL bindings.
This means a proper, formalised anatomy of a topic; cutting out some bogus things that
CommandAndCGIScripts cruft has given us (a 3rd-party service leaning on the published WSDL can't
possibly care about scoping backlinks of a rename to just the local web or all of them); coming up with a real way for 3rd-party service to react to Eg. partial rename success (Eg. don't have permission to fix
all the backlinks).
We should probably move this over to Development, and make a brainstorming topic out of it
--
PaulHarvey - 17 Sep 2010
HijaxPlugin looks interesting for a quick solution and REST would make sense. The MediaWiki client doesn't do anything very fancy and probably doesn't do attachments anyway, so it's not a very demanding requirement. If someone is going to do a full API that's a bigger project - some clients might care about details like scope of backlink renaming, though, particularly if the user is a Foswiki administrator who doesn't have SSH access to the Foswiki server itself, so this CLI tool might be their main option for scripted operations.
Incidentally I started looking at this as a way of extracting two
MediaWiki instances into separate directories to do a
diff
as part of merging their content - happened after an 'interesting'
MediaWiki migration that partially worked, with some users updating the new instance and others on the old... Being able to use Linux or PC tools to merge files without requiring server access was quite useful, and in our IT environment I don't have CLI access to the server.
--
RichardDonkin - 17 Sep 2010