Question thread #51

[pauamma]

It's time for another question thread!

The rules:

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)
- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

Comments

[ironymaiden]

I see that there's a git pull request called "API framework" and that it's untriaged. my understanding is that the API is the main blocker for mobile app development.

how does the DW pull request process work? (i.e. does untriaged mean that no one is looking at that right now, or does it stay "untriaged" until it has a review complete, or something else?)

(i really really want that mobile app.)

[pauamma]

I think "untriaged" is a meaningless artifact when it comes to pull requests (as opposed to bugs proper). That said, it looks to me from https://github.com/dreamwidth/dw-free/pull/2015 (is that what you were referring to?) that people are looking at it/working on it, so there is hope.

[ironymaiden]

Maybe I'm confused. I thought pull requests were code awaiting approval to be merged into the project. So I can see that people have been contributing API code, but it seems to just be sitting there. No comments, no other tags.

[denise]

That particular PR is from the working team that's drafting "API 2.0" and in this case is a checkpoint PR -- even if it were merged, it wouldn't be a full, working API yet. That PR is just like saying "hey, here's the bones of the thing we've got laid down already, are we on the right track?" The next step is that mark will review the bones for content, style, architecture, load, security, etc (and it is on his to-do list) and provide feedback, both of the "how this particular PR needs to be changed" and "hey, keep this in mind for when you add the next set of API calls" variety. Mark's day job has been unexpectedly busy lately, though, so he hasn't had the uninterrupted block of time necessary to do the code review!

(I totally know that the lack of a mobile app is the biggest problem most people have with DW right now! But we're putting as much of our attention to it as we can.)

[apparentparadox]

I've got some experience with iOS programming, what can I do to help with a mobile app on iOS?

[pauamma]

At this point, I think the biggest hurdle is the lack of a modern API for client applications to call. There's work in progress toward designing and implementing one, but I think it requires more server-side experience than client-side at this time. Even given that, you may want to look at https://github.com/dreamwidth/dw-free/pull/2015 (which is a checkpoint of the current work) if you want to see where they're headed and maybe provide feedback from the client-side point of view, like "this API call may be hard to use from a client, because of $reason".

[apparentparadox]

Thanks. I'll take a look at that.

[gushi]

Is the Flat interface still supported? Moving over from an old LJ client (JLJ) doesn't seem to work. If so, it's somehow different from LJ's, and I'd love to know where to find what's different so I can fix the client.

[pauamma]

As far as I can tell, it still is. See cgi-bin/DW/Controller/Interface/Flat.pm and (for the bulk of it) sub do_request in cgi-bin/LJ/Protocol.pm. But there's been some changes to both the flat and XMLRPC APIs, mostly related to the friends list split into watch and trust lists. Maybe your client is hitting one of those?

[gushi]

Okay. Let's back up a few steps.

How does one check out the source? Is there a coder's primer somewhere?

LJ, back in the day, at least had some docs for API developers that weren't actually *in the code* (http://www.livejournal.com/doc/server/ljp.csp.flat.protocol.html).

Would DW be interested in a similar document if I could contribute one?

-Dan

[denise]

The code is on github: dreamwidth

Useful developer info is on the volunteer wiki; I'm on mobile right now and don't have the patience to argue with Swype until it stops correcting the url, but check the "some rights reserved" link in the footer of webpages; that leads to our open source info page, which includes a link to the wiki.

I know we updated a few of the xml-rpc methods for the access/subscribe split, but most everything should still work. What errors are you getting?

We pulled out the server docs because the version we forked from LJ was hella out of date. Right now, it's probably not worth the time to write a more up to date version, because we're actively working on a version 2.0 of the api and once we get that working, the old ones will be deprecated. But if we accidentally broke the old one and it's an easy fix, we're happy to take patches, or even a specific bug report with what's busted!

[gushi]

Turns out this was all pilot error. Code was trying to call (with backticks!!!) a copy of markdown that was no longer installed, so was left with a null body. (It's not a well-written client, but it works for those of us that live in a unix terminal).

Thanks!

-Dan

[denise]

Ha, good to know!

(FYI, if you start a post with "!markdown" on a line by itself, the site will interpret it as markdown, so you don't have to call out to a local copy.)

[gushi]

Oh yes, and I *love* this because the markdown is preserved if I decide to edit it later. Best feature ever.