![[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
NNTP :-p
Well, I'm only half-trolling. Consider where I patch my news client to talk to DW, and so each journal is a newsgroup, and each post the head of a usenet thread. Then I can say "Any new posts or comments in
If we're not going to present DW as if it were usenet (shame!), then I think the features I'd like are around making it easier to track new comments as well as articles, for instance:
"What comments on this post are new?"
"What posts in this DW / readinglist have new comments?"
[similar web UI improvements would be grand, too, but that's not what we're talking about here]
no subject
However. If YAAPI is done right, it would be entirely possible for someone to develop a third-party pseudo-news-server that acted as a Dreamwith gateway. If they were feeling particularly clever, they could make messages with a Supersedes header edit the appropriate entry or comment iff it belonged to the person sending the message.
Such a gateway would have to be either run as its own instance per-user or associate an OAuth token with an account on the gateway.
It would be a big project, but it would be a cool one.
Read/unread state can be done in the client if there is (for example) a call to return IDs of posts and comments newer than $TIME in $JOURNAL
no subject
So I'm aware how much easier they make something that is very difficult with the LJ way of doing things: extended discussions involving more than two people. As it is, unless you track a post, you only get notifications to your comments, not for any others, and unless you actively go back to a post to look, you don't see them. Tracking comments is crucial.
When I was pondering doing an OLR for LJ, I looked at the LJ API, but the thing that it was missing was indeed a call that said 'give me all the posts and comments in journal x since time t'.
Doing it via NNTP would save a pile of work, because of how many news readers exist.
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