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