On 17/04/2012 18:11, Stephen Jolly wrote: I wrote a thingy for that, but it's a patch to a non-standard search page for RGL and not a patch to Openguides itself. If anyone wants to port it to Openguides proper, then please feel free to take it: http://www.cantrell.org.uk/david/private/index.html as written, I don't think it needs any server-side magic at all, as it's all client-side Javascript. Only tested on my iPhone, because that's the only place I care that it works :-) -- David Cantrell | Official London Perl Mongers Bad Influence Just because it is possible to do this sort of thing in the English language doesn't mean it should be done

On Tue, 17 Apr 2012, Stephen Jolly wrote: what do you mean by api? lots of data is availale as rdf and json. -- bob walker everything should be purple and bendy http://randomness.org.uk

On 17 Apr 2012, at 23:50, Bob Walker wrote: Is there a convenient way to find out what data is already available in explicitly machine-readable forms? I'd be happy to take a look and see if I can make some more specific suggestions. S

On 20 Apr 2012, at 12:01, Bob Walker wrote: The JSON representations (which I was previously unaware of) look like a very useful step in the direction I was thinking of. To answer your original question, my ideal API would have all the features necessary to create independent user interfaces to an OpenGuide (a native mobile application, perhaps), or to incorporate queries to an OpenGuide into other websites. Readily-parsable, stable representations of the node pages is a big part of it, and similar representations of the global category and locale lists would also be useful. The other obvious and significant missing piece would be JSON (or similar) representations of search results - http://london.randomness.org.uk/search.cgi?action=search&search=fish;fo… currently throws a 500, for example, which is arguably a bug all by itself... A standard way to update node contents and metadata would also be needed, although arguably the existing form submission system could be used. A JSON representation of the "recent changes" page would be an additional convenience, as would be one for the user preferences page. A good API would also fulfil some non-functional requirements - primarily good design (simplicity, consistency, principle of least surprise, etc - eg adding ;format=json to a request should return a JSON representation wherever reasonable, and fail gracefully otherwise), and good documentation. Is that helpful? Feel free to disagree with any or all of it. :-) At the end of the day, the difference between a web API and a website with machine-readable data representations isn't necessarily huge, particularly if the URL structure is already sane - it's more about thinking of the way that a developer would want to be able to interact with the server as well as thinking about how a user would want it to behave. Oh, and a specific useful addition to the JSON representation of node content would be the image details (where available). S

On 27 Apr 2012, at 11:29, Kake wrote: Yes… scripting use cases are IMO slightly different because there's generally a programmer (and usually *the* programmer) on hand to fix them up if the details of the form being auto-submitted have changed. Done. A good question, tactfully phrased. :-) Whenever I use an OpenGuide (and that's generally RGL right now) from a smartphone (which is the usual way I access it), I think "this is a faff" and start designing an elegant native application interface in my head. So far, it has not made it out of my head and into reality. That's partly because, at present, it seems that writing such an application would involve (a) learning an awful lot about the source code on which OpenGuides are built and (b) taking on an unknown commitment to updating the application whenever someone makes an internally-consistent tweak to an apparently-unimportant feature of the code (like changing an HTTP POST to a GET, or modifying a URL). I've been in a position previously of trying to maintain a native application that's pretending that a web site can be treated like an API, and it wasn't a lot of fun (although in that case, there was a lot more screen scraping than would be the case for an OpenGuide app, even with the code as it is today). Full disclosure though: although I believe that all of the suggestions I've made would make OpenGuides that implemented them subjectively better (for my example use case and for others), I don't look at my life and see an app-development-shaped hole in it this summer. So take that into account in any prioritisation of enhancements. S

On Sat, Apr 28, 2012 at 11:07:18AM +0100, Kake wrote: You've mentioned that offline editing would be useful, but why aspire towards offline browinsg too? That would presumably need a way of interrogating changes in a global edit timeline to update efficiently a local cache. One of the main problems I foresee with native applications is the nonstandard wiki markup (feel free to tell me that I'm wrong and that the wiki markup is in fact interpreted by many standard libraries - I'm not particularly up-to-date in this area) so I wonder whether some improvements might be needed in that area. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

On 28 Apr 2012, at 11:07, Kake wrote: I suspect it would solve a lot of the problem - but web design is not my strong point, so it's hard to say for sure. :-) (Not that I'm claiming that native application design *is* my strong point…) S

On Tue 17 Apr 2012, Stephen Jolly <steve(a)jollys.org> wrote: This isn't a small thing either, so ticket created at http://dev.openguides.org/ticket/287 - thanks! Kake