denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
This entry will be stickied in [site community profile] dw_dev for at least a few weeks; please point people at it if they haven't seen it!

Apologies for the delay on writing up guidance on this, folks; we were wrangling out the last of the details. (Or rather, we were wrangling enough of the details for me to make this post; I'm sure there are multiple remaining details unwrangled, which we'll figure out as we go.)

Starting now, and thanks to Bugzilla's sad demise, we will be starting a trial period of using Github Issues to keep track of our bugs. It's possible that it won't work out for us, but right now the downsides are outweighed by the very strong advantage of having everything in one place and the heavy integration.

We will not be importing the entire Bugzilla database, for two reasons: one, putting together something to port over all the data is effort that would be best spent elsewhere, and two, it's been a long time since we've been through the list to cull things that are no longer features that are no longer needed and bugs that are no longer manifesting. We decided that starting fresh with a blank slate and only entering things as they come up will be a good way of making sure the list is only full of relevant things.

This post will be about two things: how to log bugs and how to find bugs to work on. There will be a future post on how a particular item (issue) will move through the workflow with you; we have a few last little things to clear up there first, but I wanted to get this posted as soon as possible so people could start work again.

Of note:

* Please only use this process for code-related bugs. We're not yet 100% certain what the process for docs bugs will be. For now, if you spot a FAQ that needs to be changed or needs to be written, report it with a comment on this entry in dw-docs.

* DO NOT use this process for security bugs. If you think you've found a security bug and want to report it, email (private support category) and we'll take it from there.

* Part of this transition involves declaring total bug amnesty. If you had a bug assigned to you in Bugzilla, and decide that you don't want it anymore (or if you've forgotten about it completely), you're off the hook. (Not that you couldn't have been off the hook at any time anyway, but I know how hard it is to admit defeat sometimes.)

* On the other hand, if you had a bug assigned to you in Bugzilla, and you're still working on it or were almost ready to submit a pull request, we still want it! Open a new issue in Github for it and carry on.

* Just because we're not making a concerted effort to migrate every open bug from the old Bugzilla database doesn't mean that we don't want bugs to be re-reported. If you logged a bug in Bugzilla (or remember a bug from Bugzilla), and the bug is still happening and still annoying you, please open an issue for it. I will be trying to go through the last year or so of still-open bugs from Bugzilla to find "bugs that are still bugs" and re-create them, but I can't guarantee how long it will take me and I'd rather the bugs get logged sooner than I can commit for-sure to doing it, especially so that we have a nice collection of stuff for people to pick from if they just want to pick something up and hack.

That having been said:

Logging bugs )

Finding bugs to work on )

There you have it! It will probably take a little bit of getting used to (I know it took me a bit to figure it all out) but -- having gone through the process a few times in the course of figuring things out -- it really is very straightforward once you start doing it. The biggest gotcha, I think, is going to be remembering to set the milestone for all the unclaimed bugs. (That's part of the reason why we're considering using labels for that functionality instead of milestones; there are benefits and detriments to both. Fu and I will decide in a week or two once we see how a small scale test works out.)

Please take this chance to log all the bugs you're still working on, and all the bugs you can think of as still affecting you, over the next few days! Once that's been done, I'll start going through the various "upkeep" tasks (new themes, new embed sources, etc) and add those, then start working through the [site community profile] dw_suggestions posts tagged "bugzilla: migrated" to see which ones should be moved over to GHI.

([personal profile] ninetydegrees, I know you have spreadsheets for themes that were in Bugzilla and not yet patched; if you want to add those, that would be awesome, but if you don't have the time/energy, I will get to them when I fill in the various "is: upkeep" things.) (Also, I will explain the "is: upkeep" and how that differs from other "is: foo" tags in a few paragraphs!)

Again, I'm sorry for my delay in writing up the guidance for What We're Doing With This -- things took a little more discussion. Thank you all for being so willing to roll with things and try out new workflows.

If you run into questions as you work, just holler.

Appendix: What the labels mean: a work in progress )
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
It's storytime with mama rahaeli: I think we've got a legacy 'feature' that can be removed, but I'm not 100% sure. Read the background and try to convince me one way or the other.

The situation as it is now: If you try to post to your journal with a time before your most recent entry, you are prevented from doing so.

(The check is in cgi-bin/LJ/, lines 1323-1327; the error is "You have an entry which was posted at $u->{'newesteventtime'}, but you're trying to post an entry before this. Please check the date and time of both entries. If the other entry is set in the future on purpose, edit that entry to use the \"Don't show on Reading Pages\" option. Otherwise, use the \"Don't show on Reading Pages\" option for this entry instead.")

This check was added in the LJ days (I'm not sure when, because the web gateway to LJ's source is down right now and I can't look up the history, but it was very early in my tenure so I want to say 2002 or so) to prevent a very common problem with people's computer clocks being set wrong. It was a horrible support burden (leading to dozens if not more support requests per day): someone's computer battery would be dying and their clock was set wrong because of it, or their clock would just be set a year or two off. Because entries in personal journals are displayed on the Recent Entries page by the time they're dated, not by the time the server received the post, a post dated 1970-01-01 would disappear completely: the person would post it, it would display on Recent Entries behind every other post they'd ever made, and they wouldn't be able to find it when they loaded their journal to see it so they would assume it hadn't been posted at all.

(This is not a problem in communities: to avoid the problem with having posters from many timezones, communities show all entries ordered by server time, not by user-supplied time.)

The fix definitely helped that problem, but it introduced the opposite problem (someone who posts once with an accidental date of 2038-01-01 then has to do some farting around with the backdating flag) and the whole concept of backdating in general is very hard to explain to people. It also, for us, causes issues with emailed-in posts: when someone emails a post to the site, it's posted with the timestamp in UTC (aka, DW server time), which then causes problems if someone wants to post within the 'window' of their timezone offset. (This is what made me start this post: I emailed in today's stupid kitten pic, which got a timestamp of 2014-04-21 0500 UTC, then I tried to post a second entry at 2014-04-21 0421 EDT and got the error. I've opened an issue for applying timezone offsets to emailed-in posts, but there's still the wider question to address.)

My gut instinct is that this check may have been necessary in 2002 (or whenever) when very few people had self-correcting clocks, but now it's 2014 and I don't think there's a single operating system out there that doesn't ship with the "update from timeservers" checkbox checked. I think the few people who will have disabled that auto-time-correction will be used to things behaving weirdly for them if their clock is hella off, and any potential support burden will be alleviated by the lack of having to support questions like "I posted an entry in 2020 to future-date it and now I can't update without errors".

So, discuss:

1) Do people think we can safely remove the "are you trying to post in the past" check?

2a) If not, should we switch to using system time for the "are you trying to post in the past" check? (IE, go by "time the entry was received by DW" rather than "time the user specifies for their post".)

2b) If yes, which of the two options should we take:

2b1) Eliminate all future-date/past-date checks when updating, but otherwise leave things as-is, so that entries on a personal journal's Recent Entries page are still displayed in the order they're dated, not the order they were posted;

2b2) Eliminate all future-date/past-date checks when updating, and switch to treating personal journals like communities, in which entries are displayed in strict order they're posted regardless of date specified by the user.

(I can make up some examples if people are confused about the distinction.)

I think we should get rid of the check, and we should otherwise leave things as-is (so: yes to 1, and of the two, option 2b1) but I am willing to entertain arguments in any direction. Convince me!
darael: Black lines on a white background.  A circle, with twenty-one straight lines connecting seven equally spaced points. (Default)
[personal profile] darael
Dreamwidth's APIs are poorly documented (people basically have to work off docs for old versions of LJ's APIs). They're also missing key features, like comment handling for more than backups.

I've been told there have been "some internal conversations about deprecating the XML-RPC API -- keeping it for backwards compatability, but moving to a much more modern second-gen API", but that nobody has had both the time and the inclination to work on designing such a thing.

Well, this is me, volunteering. To that end, I'm looking for input on what exactly such a new API needs to provide, and whether there's a preferred underlying technology to build on (exempli gratia, stick with XML-RPC? Change to SOAP? Use JSON? RESTful or not? et cetera). What I'm getting at here is that I'm entirely happy to take point, as it were, and to make decisions (especially where there's little or no consensus and someone has to make the call), draw up specs, write docs, and so forth, but the result is highly unlikely to be a really useful API unless I get input from more sources than my own experience and looks at the code.

At this stage, therefore, I want everything you, the reader, have to say on the subject. Use cases especially.

kaberett: A sleeping koalasheep (Avatar: the Last Airbender), with the dreamwidth logo above. (dreamkoalasheep)
[personal profile] kaberett
All aboard the oh-gods-oh-gods-oh-gods we-haven't-done-one-of-these-since-November GET ON THE BUS.

Ordinarily, I would take you on a chronological tour, starting with the bugs touched longest ago and finishing with the most recent exciting work. Because of Reasons, this time we are instead playing the game of going from the bug that was reported longest ago to the one that was filed most recently. Spot the diiiiiifference. (Dear cataloguers of the future: the most recent bug in this lot is 2165, committed on 2014-03-10.)

Read more... )


And also: thank you all; you're great. <333
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
1) People who do not have write access to the repo can't change labels or milestones, so ignore all the bits about changing labels and milestones in yesterday's entry. Somebody with commit access will have to add the labels and change the milestones when an issue is submitted and when somebody decides to start working on an issue.

2) We did discover that it's possible to assign issues to people once we add them to a read-only team membership of the repo. I've added people who have open pull requests and assigned the issues they're working on to them.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
[staff profile] mark

Hi all,

First, I'm sorry for the delay in posting this and, in advance, quite sorry for the problem.

Bugzilla has died. In a rather messy and, unfortunately, irrecoverable way. The long story short is that, for historical reasons, it still ran on my personal server. I had a human-error incident with said server the other night and, alas, it was the kind of incident that ended with me accidentally deleting the server and all of its data.

Further unfortunately, I thought it was actually backed up on EBS (one of Amazon's storage systems). It wasn't. (Or well, more accurately, the root volume was -- so I still have /etc and such. But no actual /var/lib/mysql or /home.) I contacted Amazon to ask for help and they heroically tried, but it was to no avail.

In good news, we actually have substantially all of the data collected across our collected email accounts. We can recover things we want to keep, so very little is actually gone.

What's next? Well, we're going to take this time to take a step back and think about how we do bug/task/feature/etc management and how to fit that into the GitHub Issues system. Since we already use GitHub, there would be some advantages to having a centralized system that fits in with the rest of our workflow. (If you've got experience with GitHub Issues and have some advice, please let us know!)

More details will be coming sometime in the next week or two.

denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
Bugzilla is temporarily down due to server problems. We'll keep you posted!
kareila: Rosie the Riveter "We Can Do It!" with a DW swirl (dw)
[personal profile] kareila
Every few months, I run through [site community profile] changelog compiling a list of who has been contributing patches to our code repository, with the understanding that this is not a competition, or any sort of "high score" list. It's intended as a guide for casual developers, to discern not only our most prolific contributors, but also those who have contributed to the project most recently and therefore would be more likely to provide a timely, informed response to development questions. That is why the list is sorted by "Latest" instead of "Changes".

In general, one commit on Github equals one point in the "Changes" column, but fractional points are awarded for collaborative efforts — the most common example being a new S2 theme, where usually half credit is awarded to the theme author and the other half to the person who converts the theme into a code patch. Due to the nature of development, some changes are massive contributions of new code, and others are tiny tweaks; there is no correlation with the amount of effort involved. We are grateful to everyone who helps to improve Dreamwidth, in ways large or small.

I last compiled this list at the beginning of October. Since that time, we have welcomed [personal profile] forests_of_fire as a new contributor! Congratulations and thank you again!

  #  User                      Changes     Latest
  1. fu                           1577     Mon Mar 10 11:14:50 2014 UTC
  2. ninetydegrees              693.93     Mon Mar 03 20:22:10 2014 UTC
  3. hotlevel4                      26     Sun Mar 02 22:18:52 2014 UTC
  4. exor674                       328     Sun Mar 02 15:44:46 2014 UTC
  5. nornoriel                    15.5     Thu Feb 27 19:58:39 2014 UTC
  6. denise                     402.08     Tue Dec 31 06:25:40 2013 UTC
  7. foxfirefey                    102     Thu Dec 26 04:59:42 2013 UTC
  8. momijizukamori             202.16     Mon Nov 25 17:27:42 2013 UTC
  9. mark                        519.5     Mon Nov 25 05:25:11 2013 UTC
 10. purplecat                      16     Sat Nov 09 15:24:39 2013 UTC

 11. forests_of_fire                 1     Sat Oct 19 18:19:34 2013 UTC
 12. timeasmymeasure             13.33     Sat Oct 19 16:08:11 2013 UTC
 13. dancing_serpent              24.6     Sat Oct 19 15:50:17 2013 UTC
 14. swaldman                       77     Sat Sep 14 14:41:11 2013 UTC
 15. stormerider                     6     Tue Sep 03 03:33:46 2013 UTC
 16. kaberett                       13     Wed Aug 14 00:00:28 2013 UTC
 17. kareila                     791.5     Mon Jul 29 17:29:27 2013 UTC
 18. meludame                        7     Mon Jul 29 12:03:28 2013 UTC
 19. deborah                        51     Sat Jul 27 05:48:42 2013 UTC
 20. alierak                        18     Thu Jul 18 03:27:12 2013 UTC
The rest of the list... (142 total) )
foxfirefey: A guy looking ridiculous by doing a fashionable posing with a mouse, slinging the cord over his shoulders. (geek)
[personal profile] foxfirefey
Heads up for any dev folks in the Seattle area--I'm going to be hosting a DW Codefest at the Seattle Attic this Saturday from 10:30am-2:30pm PST. This is mostly for me to work on projects I keep putting off, but if anybody else happens to be in the Seattle area and wants to drop by and work with me or get advice, you are welcome! I will also be on IRC if anybody needs any virtual mentoring.
foxfirefey: A guy looking ridiculous by doing a fashionable posing with a mouse, slinging the cord over his shoulders. (geek)
[personal profile] foxfirefey
I'm pretty sure this is a question for the magnificent [personal profile] exor674, but here goes:

Let's say I convert the index page over to controllers/TT--it has two different versions, one for dw-free and one for nonfree!

How would one override the dw-free controller and/or template with the dw-nonfree one? What if one only needed to replace the template but not the controller, or visa versa?

ETA: Later I might try experimenting with detecting if a "" exists or whatnot, but my initial attempts at translating those pages with dw-nonfree are running into an interesting snag! Logged in it loads fine, logged out, there's some magical redirect that keeps happening until it goes boom. I'm trying to trace through the code to see where this is happening but no luck so far.

ETA2: Okay, the redirect was me forgetting to add anonymous => 1 to the controller call, woo! For the home page that sends it into a never ending loop of despair instead of being obvious. So far experimentation proves that putting a template with the same name in the dw-nonfree/views overrides dw-free/views, which is very good I think!

ETA3: Confirmed that just putting a new controller in dw-nonfree/cgi-bin/DW/Controller does not override the dw-freecgi-bin/DW/Controller/ one. Going to try [staff profile] fu's suggestion of hooks to add in extra variable content to the template rendering!
foxfirefey: A guy looking ridiculous by doing a fashionable posing with a mouse, slinging the cord over his shoulders. (geek)
[personal profile] foxfirefey
So, lately I've been doing a bunch of SASS work for our Foundation revamp. It can get tricky debugging CSS problems sometimes when the CSS is generated by SASS because the line output doesn't really have an easily found relation to the definition you originally made! Fortunately, there are ways to remedy this, so you can get the line number of the rule in the SASS instead of the resulting CSS.

First, you need to compile the CSS with source maps. It adds in the extra information to the CSS output for the debuggers that can read it. Add this to the bottom of config.rb, in dw-free and dw-nonfree, then recompile:

sass_options = {:debug_info => true}

Now you just need to enable the SASS line number output for the browser you are in. For FireFox, use FireSASS. Here are instructions for Chrome. I am sure other browsers have other methods!
misskat: Kat, supporthelp (supporthelp sheep)
[staff profile] misskat has to do with ticky boxes not tickying other ticky boxes correctly on the notification settings area. I have no idea how complex this will actually be, but from where I'm sitting, it looks fairly uncomplicated. I've got a user actively asking about getting this fixed, and I'd like to see it done sooner rather than later.

azurelunatic: Bust of Archimedes. &quot;Eureka: (interj) the bath is too hot.&quot; (bath)
[personal profile] azurelunatic
There's a code push coming up in just under 6 hours tonight!

9 patches in this code tour! (So far, unless Momiji sneaks one in under the wire.) 10! 10 patches!

Executive summary: Themes for 3 styles, a fix for that random profile-collapsed-sections thing, a fix for the seriously long comment hierarchy indicators not wrapping, and some miscellaneous non-journal-area (inbox, recent comments, and site pages) tweaks.

Patches from [personal profile] momijizukamori, [personal profile] hotlevel4, and [staff profile] fu, themes from [personal profile] dancing_serpent, [personal profile] forests_of_fire, and [personal profile] timeasmymeasure, and guest starring suggestions and miscellaneous bugwork from [personal profile] ninetyd, [staff profile] misskat, [personal profile] ladyasul, [personal profile] cesy, [staff profile] denise, and chronologically last but certainly never least, [personal profile] exor674. PLUS [personal profile] exor674'S LAST-MINUTE PATCH WHEE

I'm sure you will find many ways to have a good time! )

A four hour tour! A four hour tour! )
cme: The outline of a seated cat woodburnt into balsa (Default)
[personal profile] cme
I just received this as an email forward, with a note that the 2002 survey was what produced the 1.1% women in open source figure that people quote so widely.

I'm interested to see if anything has changed in 11 years. Please consider participating- the more data the better.
Ten years after the successful FLOSS survey with over 2500 respondents, which had a major impact in community, academia and even politics, we want to recreate the survey with the goal of seeing how the community is nowadays and how it has changed.

If you are a contributor of any type (not only a developer!) to FLOSS, we encourage you to participate in the survey. It takes around 10-15 minutes.

We would also be grateful if you disseminate this announcement among your community and peers. More information about the survey, including privacy, results, authors and publications, can be found at

The FLOSS2013 team
floss2013 at
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[staff profile] fu
Sooo I just filed a new bug to fix the contrast for some text on Foundation pages:

It seems like a good way to get started learning how to use Foundation/SCSS, so I'm putting it out here!
fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[staff profile] fu

SCSS directory structure

All our SCSS files are in htdocs/scss/; compiled versions are automatically placed in htdocs/stc/css. We care about the former when editing, and the latter when including them in the webpage itself.

One of the things that SCSS is really good for is making it easy to organize CSS. I'd like us to move away from CSS for individual pages, and instead concentrate on having components that are used on multiple pages.

  • htdocs/scss/foundation - stylesheets from the Foundation library. The main files to touch here are foundation.scss, which specifies the components we'll be using on all pages, and _variables.scss, which sets default behavior / appearance variables that are common to all site skins.

    _variable.scss should not contain any colors, because we have to take into account dark-on-light vs light-on-dark skins. Sizes / measurements are perfectly acceptable here!

  • htdocs/scss/components - stylesheets for individual components. These are included only on the pages that need them, but contain all the styling that's required within. Everything here should have a corresponding example of the HTML structure over on /dev/style-guide

    This folder also contains Foundation components that aren't used on enough pages to warrant being included on all of them (htdocs/scss/foundation/foundation.scss), but that we still need on individual pages. htdocs/scss/components/progress-bars is an example.

    For components where you want access to variables, useful for things like line-height, include the following code at the top:

    $include-html-classes: false;
    @import "foundation/variables", "foundation/components/global";

    That won't work for colors though! Things that specify colors will have to go into the site skins.

    To use a component from a .tt file:

    [% dw.need_res( { group => "foundation" }, "stc/css/components/component-name.css" ); %]
  • htdocs/scss/mixins - mixins are fragments of code that can be used by multiple elements. Currently we have one mixin which hides elements visually but keeps them visible to screenreader. This replaces the... three or four different ways we were doing it before

    To use a mixin, from an SCSS file:

    @import "mixins/screenreader-friendly";
    .element-name {
        @extend %screenreader-friendly;
  • htdocs/scss/pages - stylesheets for individual pages. Directory should mirror the URL structure of your pages as much as possible. But really we should try not to have anything here...

  • htdocs/scss/skins - stylesheets for site skins. Includes the actual skins and shared files, e.g., skiplinks, alert colors

JS directory structure

There's a lot more of the old JS hanging around in htdocs/js, but new files should follow the same basic structure as above:

  • htdocs/js/foundation - scripts from the Foundation library

  • htdocs/js/jquery - scripts from the jQuery / jQuery UI library

  • htdocs/js/components - individual components, suitable for inclusion on multiple pages

  • htdocs/js/pages - onload for individual pages; no examples yet. Preferably just the bare minimum of

    $(document).load( function() {

    } );

fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[staff profile] fu

Found this quick intro to why sass. (For our purposes SASS == SCSS, which I talked about in my previous entry)

fu: Close-up of Fu, bringing a scoop of water to her mouth (Default)
[staff profile] fu

So I'm here to present to you all our new style guide. That's on my public dev server, not yet on, so don't worry if it's a bit slow.

That page contains the components that we'll be using across the site. The goal is to have every component documented there and to have as little per-page styling as possible. That does two things: make appearance / interactions consistent across the site (good for users); make it easy to refer to design decisions when writing pages (good for developers, especially those of us who aren't really frontend people)

We've used the Foundation framework as our basis for our redesign. That gives us a clean, responsive design that is really easy to make work on large and small screens -- we've had a huge problem with our site headers and certain pages on phones / tablets; it's about time to fix that.

I recommend going over the Foundation documentation btw. They have excellent documentation. It's a good way to get started.

All our Foundation work uses SCSS. SCSS is a CSS preprocessor and it works like CSS but with additional features. You can have variables, if statements, mixins (fragments of code that are used by more than one thing).

It requires an additional compilation step to get all this goodness, but that's possible with one command. Try the following:

  • pull in the latest changes on develop

  • Go to /dev/style-guide on your 'hack. It'll be completely unstyled

  • Run this command:

    compass compile

    A couple lines will scroll by, looking like this:

    create htdocs/stc/css/foundation.scss
    create htdocs/stc/css/normalize.scss
    create htdocs/stc/css/skins/celerity.scss
    create htdocs/stc/css/skins/gradation/gradation-horizontal.scss
    create htdocs/stc/css/skins/gradation/gradation-vertical.scss
    create htdocs/stc/css/skins/lynx.scss

    That's good: that means your SCSS files have been turned into CSS, which you can now use.

The SCSS files themselves are in htdocs/scss. These are the files you'll be touching. After they've been compiled, the generated files are placed in htdocs/stc/css. These are the files that you'll be including on the page.

So if you have a file:


You include it by doing this:

    [% dw.need_res( "stc/css/components/foo.css" ) %]

One last thing, the compass compile command is good, but when you're developing, the last thing you want is to have to constantly switch from the file you're editing to your terminal window to run a command. Luckily, someone's thought of that. What you can do instead is this:

     compass watch

That watches for any changes in the SCSS files, and compiles them into .css files automatically. Leave that running in a separate window and it'll just do its thing. Just make sure you stop it after you're done developing for a session (just like you do with your Apache servers), because it does use up some resources!

Note: it's magical but not completely so. If you're working on something in dw-nonfree, you'll have to run compass watch separately in that directory:

    cd $LJHOME/ext/dw-nonfree
    compass watch

But if you're not touching anything in dw-nonfree, then you only need to run it the once.

Please jump in, poke around! Play with things. I'm happy to answer any questions :)

I plan on making several entries on the ongoing conversion. Soon to come: error handling for forms, directory structure for CSS / JS, easier way to format messages for email, etc.

jewelfox: A portrait of a foxgryphon with a beak, black fur, magenta hair, fox ears, and a neckband with a large jewel on it. (Default)
[personal profile] jewelfox

Dreamwidth apparently no longer uses authenticated RSS for its reading page. So if I want to create an app (for, say, Windows Phone) that lets you keep up with your Dreamwidth reading, I need to create an XMLRPC client.

Here's the part where I try to figure out how to do so.

This DW Github link is for an "XMLRPC transport that supports DW::Request".

And this DW Github link seems to have all the functions for displaying Dreamwidth content, including the inbox and (on line 284) your reading page.

So if I want to write an app that shows your reading page, I figure out how to use XMLRPC + DW::Request to send a getreadpage request? And then it returns your "entries" so I figure out how to parse that on the receiving end? And then I basically do the same thing for stuff like your inbox and posting, I guess ... right?

Can anyone clarify this process for me?

delladea: A stick figure child complains, "Mom, I'm hungry." Stick figure mom replies, "Hush I'm coding. You ate yesterday." (coding)
[personal profile] delladea
Hi there, I'm your code-tour driver today :D. The majority of these fixes aren't live yet, but keep an eye on [site community profile] dw_maintenance for when they'll be pushed onto the main server.

Contributors for this tour: [personal profile] stormerider, [personal profile] kaberett, [personal profile] sophie, [personal profile] hotlevel4, [profile] kariela, [personal profile] swaldman, [staff profile] misskat, [personal profile] exor674, [personal profile] ninetyd, [staff profile] fu, and [personal profile] momijizukamori.


18 bugs squished )


dw_dev: The word "develop" using the Swirly D logo.  (Default)
Dreamwidth Open Source Development

April 2014

   1 2345
20 212223242526


RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Apr. 21st, 2014 12:31 pm
Powered by Dreamwidth Studios