XML-RPC interface issue

[aslj]

(Of the official journals, this looked like the most appropriate place to post this.)

Dreamwidth's XML-RPC interface is returning some results that I would call broken. On both 'login' and 'getfriendgroups' calls, it returns empty lists rather than a list of custom access filter groups (which is what I would expect) or some combination of those and custom reading filter groups (which I would think is inappropriate given that clients are intended for posting and not for reading). The end result is that custom-group entry security is unusable (no groups from which to choose) in any client that implements the XML-RPC protocol as specified in the LiveJournal docs.

Comments

[kareila]

I don't believe mark has any intention to make DW access groups backwards compatible with LJ's XML-RPC protocol, per his comment here.

[mark]

Yeah, it won't be backwards compatible. We will provide all of the available data through appropriate methods (we don't yet; but as soon as it's needed and someone kicks us enough we will!) but we won't be supporting the exact same methods in the same way as LJ does.

We will try to support it well enough... and we MIGHT end up making ver=1 backwards compatible and make ver=2 have all of the Dreamwidth features, but nobody has really taken point on the discussion to lead the project.

[aslj]

I've spent a lot of this evening thinking about this and researching pieces of it and here are my thoughts, as a client developer with no particular interest in Dreamwidth other than a user request to make custom access filters work.

As far as I can tell, to make custom access filters work, one of two things needs to happen.
1. You make the 'login' call properly return 'friendgroups' (which would also fix the behavior in other clients)
2. I write what may amount to an entirely new client (or at least an entirely new client-server communication library) to meet a specification that does not exist (which would only help my own client or one based on my libraries)

As I can't do 2 without a spec and probably have no time and not enough motivation to do it and as you have stated that you won't do 1, my only conclusion is that I should warn my users that Dreamwidth does not support the XML-RPC protocol and that if my client or any other client happens to work with Dreamwidth, that's great, but I can't guarantee any kind of support at all.

Further, I think co-opting ver=2 to your own meaning risks very bad future breakage if LJ ever decides to use ver=2. Either extend the protocol in a backward-compatible way (adding optional extra parameters to enable, e.g., 64-bit integers for allowmask), or define a new protocol and put it somewhere other than where the LJ XML-RPC protocol is expected to be.

[exor674]

But the questions is which collection of groups should 'friendgroups' return?

[aslj]

As the client protocol is centered around editing/posting entries and does not provide any significant commands for reading other people's entries, it should return the custom access groups, the groups to which the user has given access, which are relevant for custom security when creating/editing a post.

[exor674]

What about checkfriends?

Someone passes the access group mask to that, expecting that to work just like on LJ -- and it just won't work as expected.

[mark]

I really think #1 is a bad idea -- I used to be a client developer (I wrote LochJournal), and I know that if LJ were to suddenly start spitting out 64 bit groups there'd be some bad problems with most clients. Not to mention, my client did some other things with those friend groups like give the users URLs to go filter their friends page. All of those features would just be broken and the client developer would have to special case Dreamwidth anyway.

When I was working on the client, I had to special case some sites anyway. DeadJournal was always on old code, sites would come and go, it's sort of the name of the game... if you build a client application, you sort of have to deal with changes that come down the pipe no matter who they come from. Well, I did, as I wanted to try please as many of my users as possible. Can't always do that, but eh.

Philosophically, LJ has traditionally forged its own path. That was fine back in 1999 when nobody else was really doing these things on the Internet, but nowadays there are actual standards for blogs and clients. The Atom standard, mainly, and I would rather put the time and effort into supporting that than go back and try to retrofit or jury rig these special modes that LJ based sites support that nobody else does.

I want Dreamwidth to move in that direction: to support the standards that other sites like WordPress, Blogger, and TypePad are using. If we can be compatible with those clients, we'll be in a much better position than trying to be compatible only with our little microcosm.

None of which is really going to make things better for you this very minute, of course.

Brainstorming, though...

What if the login mode returned a tuple 'dwmode=1'? Then, you could know that there are no friendgroups and that this site (whether it is us or someone using our code) is using the Dreamwidth protocol.

Further, if that's acceptable, would you be willing to implement a second call out to 'gettrustgroups' or some method that is actually specific to what we do? It should be pretty simple for your client to do, just a different method, same looking results.

If you're willing to implement and support this in your client, I'll go hack it up right now and have it out next code push. I can't promise it will be pretty code on my end, but it will work. ;)

[aslj]

That's unfortunate.

So, apparently Dreamwidth has no intention of supporting LiveJournal clients.

[kareila]

Not using the exact same protocol that LJ does, no. But there will be better support for those clients down the line, as mark outlined above.

I think in order for it to happen in a timely manner, we would need a client developer with a keen interest in getting things rolling to work with mark and/or other backend developers to design and implement an updated protocol.

[aslj]

If it's not using the established protocol as documented by LiveJournal (or at least something compatible), then it won't be support for existing LJ clients at all.

[denny]

Posting stroppy-sounding comments probably won't change that.

The LJ 'friends' concept and the DW 'trust' and 'access' concepts aren't the same. Trying to use the protocol as if they are in some circumstances would be foolish. The solution is to implement new methods, not mis-use the old ones.

I think it might be more accurate at this point to say that you're not willing to extend your LJ client to also support DW - and that's a perfectly reasonable decision for you to make.