Dreamwidth Q&A Session

[denise]

I realized this morning that it has been quite some time, so I figured it would be a good time for another Dreamwidth Q&A session!

Got a question on how the business end of DW works? Curious about the progress on a particular feature? (Although I can probably answer that for you by saying: we're working on paying down our technical debt so that we can move forward on a lot of the planned features; it got to the point where we couldn't progress further without making some aggressive modernization of the existing codebase.) Wondering what an average day in the life of a DW employee is? Got that one question that you've been vaguely wondering about for ages, but never felt like it was "important" enough to make a support request to get the answer on? Want to know if it really is that cool being able to work from home without wearing any pants? (Answer: yes, especially when it's 85 degrees F in my office and the air conditioners won't be delivered and installed for at least another day or two.)

Comment here, and we will answer!

(Just a reminder: you may receive comments or replies from people who know the answer to your question, but aren't officially DW staff. If the person who answers you doesn't have the official "staff" userhead -- -- they are not DW staff. They may be correct -- if they aren't, I will be sure to answer and clear up any misconceptions -- but they are not speaking ex cathedra Dreamwidth, so to speak!)

No question too big, no question too small. There's also previous Q&A sessions and the Business FAQs to browse through!

(Answers may be a bit slow depending on computer woes and additional stuff going on, but we will answer!)

Comments

[chris]

Following up on what I asked at the time, are there any plans to use the developed code at all - say, to permit cross-site reading from other sites using the Dreamwidth codebase, even if it's not possible to use it either on (a) sites using the LiveJournal codebase at large or (b) the LiveJournal site in particular?

[pauamma]

The way to do that with other sites using the Dreamwidth codebase is probably to have both sites work together in ways that don;t overload either, so it would likely be very different from what Mark tried to do, which was designed to work with a (mostly) passive other site. I haven't seen his code, so I can't be positive, but I suspect there would be little that can be reused in an architecture where both sites are trying to help.

So my (non-authoritative, as D pointed out in the entry) guess is: the code will likely not get released, but that's still a Dreamwidth feature we'd like to have. I'm pretty sure she mentioned wanting to do something like it, back when all there was to was a few mailing lists (summer and fall of 2008).

[denise]

Yes, absolutely that's something we want to add in the future -- we haven't made it a priority up until now because there aren't very many sites running DW code yet. That's starting to change, so I'm hoping we can start adding more of those federation type features as time goes on!

As pauamma says, though, there will be much easier ways of doing it on a DWcode-to-DWcode site relationship -- part of the problem is that LJ is not really willing to make any changes to make getting or working with that data any easier than it is right now, while with DW-code sites we'll be able to bake it straight in. It'll take more initial effort to do it that way, since it will involve a lot of backend work up front to a) implement better authentication mechanisms (we've been wanting to implement OAuth anyway, but it's sort of a prereq for the Right Way to Do This, along with a few other things) and b) change the entire concept of what an "entry" is, what a "reading page" is, what checking your reading page does, etc. It'll be a major undertaking, and we need to pay down a lot more technical debt first, but it's definitely something we're interested in doing.

[roadrunnertwice]

I'm dreaming of federation features flexible enough to work with services not married to the LJ format; an API that could be consumed and offered by Twitter-like microblogs, Instagram-like photo streams, autorebloggers like Stellar, etc. etc. Because that would be such a great way for new contenders to make a play at established lock-ins like Twitter and Flickr.

(I realize you're not even at a stage to design this stuff yet; I'm just putting the proverbial bug in the ear.)

[exor674]

we've been wanting to implement OAuth anyway...

Which I will finish one of these days, dangit.

[zvi]

*claps gleefully in anticipation*