mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)
Mark Smith ([staff profile] mark) wrote in [site community profile] dw_dev2016-12-27 05:14 pm
Entry tags:

Simplification & deprecation

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'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 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!
srukle: (Default)

[personal profile] srukle 2016-12-28 02:07 am (UTC)(link)
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?
srukle: (Default)

[personal profile] srukle 2016-12-28 02:25 am (UTC)(link)
Thanks for the info! I will carry on then. :)
wailor: (Default)

[personal profile] wailor 2017-01-04 01:13 pm (UTC)(link)
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: "Cesy" - An old-fashioned quill and ink (Default)

[personal profile] cesy 2017-01-15 09:03 am (UTC)(link)

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.

wohali: photograph of Joan (Default)

[personal profile] wohali 2016-12-28 07:32 am (UTC)(link)
Sounds great. Now to deep six the translation system ;)

[personal profile] swaldman 2016-12-30 08:33 am (UTC)(link)
I'd be all for just putting text into TT files directly, at least for new stuff. It'd make things a whole lot more readable and I can't immediately think of any benefit from having strings abstracted. But IANAsystemarchitect, so I probably wouldn't think of such benefits anyway ;-)
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

[staff profile] denise 2017-01-09 04:31 pm (UTC)(link)
I edit text live on the site all the time to make language clearer, correct errors, etc! It is a lot easier than having to do a patch & then poke someone into pushing it live...

[personal profile] swaldman 2016-12-30 08:31 am (UTC)(link)
That was also my first thought on reading this (welcome) news!
brainwane: The last page of the zine (cat)

[personal profile] brainwane 2016-12-29 07:18 pm (UTC)(link)
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". 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?
alierak: (Default)

[personal profile] alierak 2016-12-30 04:34 am (UTC)(link)
I'm not an authority on the subject, but I see us supporting two configurations for the foreseeable future: a very simple one for development, and then whatever we actually use in production. For example, userpics in production are currently in MogileFS; as Mark says this will probably switch to Amazon S3. But for development environments, it may be that just putting userpics on disk on the same server you've got running everything else is just fine. There will likely continue to be a difference between getting the basic functionality to work in dev, and making it scale for real.