Phil Mills (![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
philkmills) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
dw_dev2011-12-20 09:08 am
philkmills) wrote in dw_dev2011-12-20 09:08 am
Entry tags:
Client/Server Protocol
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.)
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.)
no subject
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.)
no subject
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. :-)
no subject