On clients and APIs

[darael]

Dreamwidth's APIs are poorly documented (people basically have to work off docs for old versions of LJ's APIs). They're also missing key features, like comment handling for more than backups.

I've been told there have been "some internal conversations about deprecating the XML-RPC API -- keeping it for backwards compatability, but moving to a much more modern second-gen API", but that nobody has had both the time and the inclination to work on designing such a thing.

Well, this is me, volunteering. To that end, I'm looking for input on what exactly such a new API needs to provide, and whether there's a preferred underlying technology to build on (exempli gratia, stick with XML-RPC? Change to SOAP? Use JSON? RESTful or not? et cetera). What I'm getting at here is that I'm entirely happy to take point, as it were, and to make decisions (especially where there's little or no consensus and someone has to make the call), draw up specs, write docs, and so forth, but the result is highly unlikely to be a really useful API unless I get input from more sources than my own experience and looks at the code.

At this stage, therefore, I want everything you, the reader, have to say on the subject. Use cases especially.

Go.

Comments

[darael]

Regarding multiple iterations: I really need to get a list up somewhere, and keep it up-to-date, of what features would be for what iteration. Thus far I can see a "ready-to-start-implementing" (at least authentication and posting and editing entries. Call it feature-parity with the Blogger API.), a "viable prototype" (enough features to actually be useful, so that's fetching comments, basic full-dump style backup, reading page), "idealised basic" (add posting and editing comments, treating them as first-class objects, icon management), "solid" (account settings, moderation tasks, &c), "polished" (everything one can do through a browser, even if it takes multiple calls under-the-hood), and what one might call "wishlist" (things that exist purely to lighten server load and allow people to make little toys).

I may be subdividing a little too finely, here, but I think the principle's sound.

I should get on that.

[denise]

I like iterations! Iterations help to prevent total burnout :)

[alexbayleaf]

I would be delighted to start working with the API as soon as it has a simple authentication/posting mechanism.

I'm already starting to brainstorm apps I'd build with just that, starting with take-a-pic-on-your-phone-and-post-it-really-easily (speaking of things that need a snappier name).

[jewelfox]

I personally wanted to build "read your friends list on your phone."

[alexbayleaf]

I occasionally think this, then wonder why it can't be more easily done by making existing site styles more responsive/mobile friendly?

afuna and I fiddled a little bit with some CSS stuff to make site scheme readable on a phone a while back. Nothing ever came of it, but if it were workable, I would actually love to be able to read DW -- just plain old web based DW -- on my phone.

[denise]

It's in progress as part of the Foundation/SCSS conversion, but there are a lot of pages to convert.

[jewelfox]

I occasionally think this, then wonder why it can't be more easily done by making existing site styles more responsive/mobile friendly?

More easily done by whom? >_>

Plus a native Windows / Windows Phone app would have live tile support, and the ability to easily share non-access-locked content.

[fu]

I like the idea of chopping things into smaller chunks.

Sooooo a suggestion for where to put up the list: let's have an issue on github for each separate feature, grouped under a milestone for each iteration -- that is vs having one issue called "implement API" with everything listed as a comment there ;)

[darael]

This is a good plan, but I don't want to clutter up the dreamwidth/dw-free github section with bugs to the effect of "this hasn't been specced yet". As such, I'm going to publish a new repository (Darael/dw-yaapi) on which the milestones and the feature-spec bugs can go, as well as the specifications to close said bugs. Then, when a milestone's complete, it becomes viable to create a corresponding milestone on dw-free and appropriate "this spec isn't implemented" bugs to go with it. That link's dead at the time of writing, but expected to go live in, ooh, five minutes? I probably don't have time tonight to actually enter the first milestone's bugs, though.

[fu]

Whoo, okay!

I don't think anybody would be bothered by having the discussion in dreamwidth/dw-free, but that also looks like a good place to start :) i don't want to step all over your thought process, but I'll keep an eye on the issues repo for updates.