lj_dev, we're going to try to resurrect the list of "what is the office up to this week!" It will be posted first thing during the week and give everybody an idea of what we're going to be up to.This is not a complete list. This is just what we've got right now. Other things will crop up during the week, and not everything on this list will get done this week, so please don't take this as 100% bona fide gospel.
FotoBilder:
- Per picture security (see clarification)
- General cleanup and other stuff to make FB pretty
LiveJournal:
- Individual user backups We want the ability to backup a single user to a GDBM file. This gives us the ability to backup and restore individual users--explained more below.
--- LJ::mark_dirty usage everywhere By using the mark_dirty API, we can determine exactly what users have data that have changed. Then, when we are backing people up, we can only backup those who have changed recently.
--- backup global tables (user row, polls, etc) Right now the user-backup tool only saves information that's clustered. Certain things such as polls and s2 styles aren't clustered yet and need to be saved from the global.
--- sign the GDBM file? (MD5 of it? use the 'secrets' system?) We want to give users the ability to download their most recent journal backup. That way, in case something happens (they get hacked and their journal is deleted or some other data loss), the user can reupload their journal backup and restore their journal to where it was before the problem.
--- generation of SQL for restoring journal This is how we take the GDBM file and convert it back into a journal--the tool needs to regenerate the SQL necessary to create the journal back in the state it was in when it was saved.
--- harness around the tool to backup based on dirtiness Given the mark_dirty API above, we need a harness that can figure out what users to backup and when to do it. This harness is responsible for getting the user's GDBM file, running the backup, and then saving the file.
- MogileFS on LiveJournal This project includes userpics, phone posts, and backup files from the backup harness. Basically we want to give LiveJournal the ability to use MogileFS for general purpose storage for any number of thing--then we don't have to rely on NFS or local filesystem access. HTTP will be used everywhere, if that's enabled.
- Add more $u->do everywhere Recently the LJ::User class was created. This class gives us an abstraction to use for such things as making changes to a journal and localizing all code that uses a user as the primary object. For right now, we are moving all occurrences of $dbcm->do to $u->do. This will also let us keep track of what queries are associated with what users for a project coming up soon.
- Final cleanup/testing of new update.bml page Please help us test! http://test.livejournal.org/ has this new code live. Please report any issues in
lj_test.- Make quick-reply support hitting back sanely in good browsers Currently, quick-reply has problems if you click the submit button and then hit back. It tends to lose your comment and where it was supposed to go. David is working on fixing this behavior -- or at least making it more sane.
General:
- Switch to Subversion CVS just doesn't provide enough functionality for our purposes. Notably, we want to move some code around and want to be able to rename files and delete files without having to hack the repository manually. Subversion also provides cheap branching and more fine-grained access control, which will come in useful.
Lemme know if I missed anything, guys.