schema documentation
Progress so far. I don't think that belongs in /admin/, btw... what's a better URL for it? /dev/ ?
By logging in to LiveJournal using a third-party service you accept LiveJournal's User agreement
Multiple MySQL servers running on the same database stored on an NFS store
is not something you should try at all. Threaded locking is unreliable by
itself on Solaris and Linux if I read the MySQL docs correctly, and NFS
locking is worse than that. You'd absolutely need a thread-safe flock()
implementation that works over NFS as well - good luck with your quest. :)
The FTP server's all up and running, and client authors are able to upload their latest clients to the site, but still most users can't see them.
Brad was intending to allow client authors to specify the most recent version and filename, etc, but I believe it would be easier to allow client authors to upload a bunch of bml files (probably just index.bml) containing links and other information.
This would allow for things that are more complicated than simply a download link where needed, such as information on how to build LoserJabber from source, links to download source code separately or links to download MFC and mIRC.
I see there's already a /clients/ directory, of which only win32 actually has anything in it. This would be a good place for it. The download page could then be changed to simply display something like this:
Client Name | OS/Platform | Description | Authors |
---|---|---|---|
LiveJournal | Windows9x/NT | The client most users will want. This is the main LiveJournal client for Microsoft Windows platforms. | Tim Yardley Brad Fitzpatrick |
LizardJuice | MacPPC | Newer client for Apple Mac users. | ??? |
LoserJabber | Gtk+ (Linux) | A very cool client for Gtk+. Gtk is currently only popular on linux, but this could change in the future. | Evan Martin |
LiveJournal for BeOS | BeOS | A client for the relatively unknown (but still really cool) operating system BeOS. | Simon Huet |
... and so on ... |
The stuff on the other end of those links would be bml pages (and maybe images... I don't know: screenshots?) written by the client author and synced over from a "web" subdirectory of their client's directory within their FTP space. The contents of this directory would be able to be replaced, unlike the ones within the file directory, and filetypes restricted to avoid the temptation to put downloads in the directory. (since they should be going in the file area, where the security is slightly better... no replacing allowed)
As a final touch, BML... um... thingies (I forget the correct term) could be added to automatically make FTP and HTTP links to particular files so if the download stuff needs to be moved around in the future, the links will automatically update to point at the same file elsewhere on the web and FTP servers. (http://download.livejournal.com/ for the future? Possible...)
Yikes, that's long. Sorry, I know it's a lot of text but I think it'd be a good idea nonetheless. I'd also like to see the thing for client authors to be able to set messages to be sent to particular versions of our clients... it would be a particularly useful addition to the whole "allowing client authors to do their own thing without badgering Brad" movement.