Simplification & deprecation

[mark]

Historically we've had a policy of trying to actively support people who might be running the DW code somewhere and that has influenced how we've built things, such as making many things options in the codebase and also maintaining support for legacy configurations and systems that we might not use in Dreamwidth.org's production environment.

Since there's not (and never much has been) people seriously running DW code for any major service, I would rather for us to focus our limited development resources on our own development needs. To be totally clear, we will continue to maintain Dreamwidth the open source platform and people are very welcome to use it. You just might have to either do some of your own development or use a production environment that closely mirrors ours.

Some examples of what this update means:

* Perlbal is no longer used at DW HQ and we're removing all support for it
* MogileFS is on its way out (to be replaced by either simple on-disk storage or Amazon S3)
* Master-Master support is deprecated and will be removed
* Configuration options are being cleaned up and some things will become non-optional (i.e. compression, etc)
* No more support for 32 bit systems (think this is gone already tho)

My goal here is to make Dreamwidth development faster and easier for actually developing on Dreamwidth.org. We'll still have to make it possible (and easier!) for people to run DW (if nothing else for our own developers!) but the number of at-scale-production-configurations supported is going down.

As always, comments welcome!

Comments

[casimirian]

Glad to hear you're taking such a pro-active approach to DW-dev. I'm curious if these developments will make a change in how clients can interact with DW. I'm actively working on DW API for Python and an old perl-base client (though I intend to create a Python client using old, old code). I'm not entirely sure how the old code works, but I'm making flowchats of it now. Will tools such as ljdump, jlj, charm, etc. stop working for users?

[wohali]

Sounds great. Now to deep six the translation system ;)

[brainwane]

I do not hack on Dreamwidth and only have a passing familiarity with the nuts and bolts of the architecture, so I had not realized how much effort y'all had been putting into supporting forkers/competitors. (And, I speculate, into making it easier for feature improvements and bug fixes to (under ideal conditions) flow back and forth between LJ and DW.) Your new suggested approach sounds like a good one to me, as a way to make the lives of actually-existing and likely-to-exist Dreamwidth developers easier and more productive.

The extreme version of this approach, as I see it, is: "You can only expect to run the software in this one configuration because we have taken out all the options we don't use for dreamwidth.org". So, how far are you interested in going in that direction? Or, to put it another way, what options do you think should still remain optional?