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

[srukle]

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?

[mark]

No, we're not breaking the API. That'll live on a long time. We have some on-again-off-again plans to provide a new, modern API, but that hasn't happened yet.

[srukle]

Thanks for the info! I will carry on then. :)

[wailor]

I'm looking forward for that new API. Last year I started to develop an Android client because of the lack of a responsive design (that makes the action of publishing new entries pretty annoying, having to zoom in and out to click on buttons and stuff like that). So far I've been able to fulfill basic features like login, list the entries of the friend page and publish new entries specifying the visibility (public/friends/private) but the strange API methods and the lack of updated documentation makes it a slow progress.

[cesy]

In theory, any lack of responsive design is a bug - the main site pages are meant to work well on mobile. So it may be easier to solve the use case problem by working on fixing those, which helps a wider range of people.