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]

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.