![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
On clients and APIs
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.
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.
no subject
The best I can hope for is to spec YAAPI such that implementing an NNTP gateway using it is pretty easy. Such a gateway would be most easily (but least usefully) done as a single-user affair, in the style of sn or leafnode, rather than a full multi-user NNTP server รก la INN or papercut, simply because the latter would need a way to associate gateway accounts with DW OAuth tokens.
And yes, I've thought about it. I mean, I came at this because places like the wiki still suggest that NNTP is a maybe-eventually DW feature, and the only place it was documented as a not-going-to-happen was on Bugzilla, which has of course gone.
In any case, building such a dreamwidth-to-news gateway would require a "give me all posts and comments in journal x since time t" call, and I'm certain that there are other reasons to have it in YAAPI as well. For non-NNTP purposes, there should probably be two other calls for just entries and for comments on an entry.
no subject
(I mean, I love tin. But the Average User can't run tin.)
no subject
Hmm, track everything of interest and use email to get all comments, hmm.
no subject