Difference between revisions of "User:Djce"

From MusicBrainz Wiki
m (User:DaveEvans moved to User:Djce: It's my page :-))
Line 3: Line 3:
 
However it's been a while now since I seriously hacked on the server (late 2004 I think it was) - these days I tend mainly to do whatever's necessary to keep things running smoothly and to keep the service available, rather than hacking on new features or bug fixes.  
 
However it's been a while now since I seriously hacked on the server (late 2004 I think it was) - these days I tend mainly to do whatever's necessary to keep things running smoothly and to keep the service available, rather than hacking on new features or bug fixes.  
  
On the main site and [[IRC]], known as [http://www.musicbrainz.org/user/view.html?modname=djce djce]  
+
On the main site and [[IRC]], known as [http://www.musicbrainz.org/user/view.html?modname=djce djce]
 
 
=Things I'm working on, or would like to work on=
 
 
 
==Server Set-Up==
 
 
 
See [[User:DaveEvans/UbuntuSetup|/UbuntuSetup]]
 
 
 
==Replication==
 
 
 
The fun bit: moved to [[Replication Revamp Feature|ReplicationRevampFeature]].
 
 
 
==Other Replication Changes==
 
 
 
* We could probably do with changing the filesystem structure of replication packets, so that we get smaller directories
 
** old: <code><nowiki>sprintf "pub/musicbrainz/data/replication/replication-%d.tar.bz2", $SEQ</nowiki></code>
 
*** starts to get iffy after, say, 10000 hours (approx 14 months)
 
 
 
** new: <code><nowiki>sprintf "pub/musicbrainz/data/replication/%d/replication-%d.tar.bz2", int($SEQ/1000), $SEQ</nowiki></code>
 
*** starts to get iffy after approx 1000 times that (over 1000 years)
 
 
 
** Impact:
 
*** Needs new code, both at the master site and all the slaves.  A whole release almost seems like overkill... maybe commit the change to the release branch, update the master, and ask the slaves to do an "svn update" at their end?  Either way it'll need to be announced via mb-datafeed beforehand.
 
*** Will cause a "spike" when next mirroring to OSL@OSU.  Still, it's a smaller spike than our twice-weekly full exports.
 
 
 
* In general: replication slave "with hooks"
 
** make it easier to run a replication slave with "hooks" for doing "stuff" with the changes
 
** should be possible to use either a near-real-time feed, or the packets
 
** would need hooks for "row inserted", "row updated", "row deleted"
 
** if the slave could be divorced from a SQL database, would also need a hook to read (the non-SQL equivalent of) <code><nowiki>replication_control</nowiki></code>
 
 
 
==User Email Verification==
 
 
 
Moved to [[Email Verification Feature|EmailVerificationFeature]].
 
 
 
==Message Board==
 
 
 
See [http://bugs.musicbrainz.org/ticket/3583 http://bugs.musicbrainz.org/ticket/3583]
 
 
 
Regarding deletion: ideally if a user's email expires (see [[Email Verification Feature|EmailVerificationFeature]]), then they log in > 1 year later, it would be nice if the message telling them about the expiry was still there.
 
 
 
----
 

Revision as of 21:16, 9 March 2012

For a while I was the main server developer. See also the MusicBrainz "Bio" page, and my home page.

However it's been a while now since I seriously hacked on the server (late 2004 I think it was) - these days I tend mainly to do whatever's necessary to keep things running smoothly and to keep the service available, rather than hacking on new features or bug fixes.

On the main site and IRC, known as djce