On 27 Apr 2012, at 11:29, Kake wrote:
A standard way to update node contents and metadata would also be needed, although arguably the existing form submission system could be used.
I do quite a lot of auto-updating/importing on OpenGuides sites - I use WWW::Mechanize for this.
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.
A JSON representation of the "recent changes" page would be an additional convenience, as would be one for the user preferences page.
Agreed - can you open a couple of tickets for these?
Oh, and a specific useful addition to the JSON representation of node content would be the image details (where available).
Can you add that to bob's ticket, or open a new one?
Done.
Do you know when you might be able to start sharing more details of the things you want to do with all this?
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