Client/Server Protocol

[philkmills]

This is somewhat related to someone's earlier post, but a bit more specific. I'm attempting to create a (different!) client application that would work with both LiveJournal and Dreamwidth. I'm discovering that there are modes that neither fail nor truly succeed when used with DW.

For example, 'getfriendspage' returns no error, also no information. Since DW uses a different concept around reading and subscribing, the idea that the mode doesn't work isn't too surprising.

Looking at Protocol.pm is confusing in that it appears to support getfriendspage (at least, there's code to implement it). I don't see that there is any equivalent interface for retrieving reading page events.

Since the functions of Protocol.pm call internal routines that may or may not do anything, is there a better way of discovering what things are actually supported and what they return?

(I've seen http://wiki.dwscoalition.org/notes/XML-RPC_Protocol but obviously that's not definitive either.)

Comments

[mark]

It looks like the getfriendspage method doesn't work. We've never updated it to work with the reading page split. It wouldn't be terribly hard, but nobody's done it.

[philkmills]

Thanks.

Any suggestions concerning the meta-question of how one is to know what to expect of any given protocol function? ...short of downloading, running, and tracing execution in a copy of the server, that is. :-)

[denise]

The page you linked to on the wiki is probably the closest that exists. We, uh, have been kind of behind on documenting things!

I will try to get somebody to put some time into cleaning that up.

(Also: this is totally why we want to move towards making more on-site things run through the protocol -- I've been vaguely embarrassed about the state of things for a while, and we've wanted to make it much, much easier for third-party developers for ages. I really am sorry that it's in such awful shape; we've been doing what we can, but we're also being pulled in like eighty different directions and nobody has really stepped up and taken this on as a project.)

[philkmills]

"we want to move towards making more on-site things run through the protocol"

That makes great sense as an approach. If the server were done as a n-tier thing where the web UI only talked to a layer composed of a published interface it would open up a lot of possibilities. Every browser reload would be QA for the API. :-)

[denise]

Yeah, exactly :) It's going to take a lot of work over time, but it is a goal!

[foxfirefey]

Maybe you already know this, I don't know if this would help or not, but you don't have to download the code to get a copy to play with if you apply for a Dreamhack--we provide sandboxes for devs to play in, so they don't have to go through the trouble of setting it up and hosting it themselves.

http://hack.dreamwidth.net/

[philkmills]

Thanks. I was vaguely aware of it from some of my reading. I'll keep it in mind if things become too confusing otherwise.

[mark]

Also, you're doing the right thing for getting feedback. This community is great, or you can come on IRC on the Freenode network and join #dreamwidth-dev and we can help there.

A lot of Dreamwidth development is pull based -- i.e., someone wants something and they make noise and then someone builds it. Since we don't really have any clients right now (all of them are LJ clients that also sort of work with DW) we haven't had a lot of contact with client developers.

[philkmills]

The biggest problem for a client developer is that there's so little in the API...whether for LJ or DW. For example, one of my starting assumptions was that a user would have access to public posts in other journals and "friend-enabled" ones in other journals...more or less equivalent to communities. It just seemed reasonable since I can do it in a browser. I probably spent a half-day believing that there was some big chunk of docs somewhere that I hadn't found. :-)

For things like the 'getfriendspage' mode, it would be really nice if they at least returned some kind of 'unsupported' error status. When doing C/S programming, it's hard to know where the problem is when a call apparently succeeds but doesn't give predicted results.