Welcome

[marnanel]

What? Dwim is (going to be) an Android client for Dreamwidth.

Why? A lot of people have been asking for this over the years. It hasn't happened because of DW's lack of workable API: the current API was inherited from LJ, and hasn't been updated to handle DW-specific features.

I have experience here. When I first wrote Joule, LJ's API didn't support the search it needed. So it worked by scraping-- that is, requesting the pages as if it was a browser, and parsing the HTML directly. Dwim should work the same way. It's especially easy with DW, because you can request pages without any styling in the way.

How? I've got a lot of ideas, but I'm carefully not diving in to coding it before we've talked about it here :) In particular we should discuss:

• the UI
• how the back end will work
• caching
• whether and how we deal with posting while offline
• what we're going to do about including images (especially for "share to DW")
• what toolkits would be appropriate
• whether anyone wants to help with coding or design or documentation
• a roadmap of what features should appear in each iteration

I don't know much about iOS development, so my horizons here are limited to Android. If anyone does, that'll be useful to know.

I'll post more in the next couple of days as I write up my notes. Feel free to post and discuss too.

The back end

[marnanel]

The back end will have to work by scraping, for now. If it's properly modular, we can replace it if-and-when a usable API comes along. We should use scraping for everything and not a hybrid of scraping and teh old API: a new API would use a different protocol from the old one, so we don't gain much by using the old one in the meantime.

There is a port of Beautiful Soup to Java, which will make the parsing much easier.

Dealing with comments is a big question, and I think we can leave it until later iterations.

Important things it must be able to do:

• Log in, and store the cookies
• Get lists of: your friends, your subscription and access filters, accounts in your circle
• Read timelines of various kinds
• Post entries

The timelines present a particularly interesting challenge. It's a shame that RSS/Atom feeds aren't a general solution because they're not available for /read pages. But we can request timelines in slices (?skip=...) and that will be enough.

We should never try to download all the entries of any timeline. Instead, when the user gets to the bottom of a timeline, if we don't know whether there are more entries, we should check then. (Like the way the Tumblr and Facebook clients work.)

I've been toying with putting together a Python prototype of the back end. It would allow us to debug it more easily.

Thoughts?