#musicbrainz

which isn't their real name, obviously.

basically, what happened there is that some annoyed last.fm users didn't want their swedish band to scrobble to the same place as the british band, so they manually edited their music files to add '(Swedish)' to the artist name.

seems like a pretty real band if you ask me... see, 3 songs here ready to be streamed: http://www.last.fm/music/The+Kooks+%28Swedish%2...

roosoft: it's a real band, it's not their real name. It's a hack to workaround the issue that last.fm doesn't support multiple artists with the same name.

their +noredirect page is also quite weird - apparently I have 3 friends listening to them, with 0 or more plays depending on which page I look at :)

I think it might be getting the scrobbles confused with the redirect or something.

I have a few mp3's where Picard gives me a nice red interdiction sign and gives the error "Error: 'ascii' code can't encode character u'\xe8' in position 7: ordinal not in range(128)"

and it fails to read them, and I can't do anything with them

(iTunes can read them all right though)

mat_: when you start picard from a console, do you get a warning about your locale being wrong/suboptimal?

Mineo, hum, trying to launch the binary directly (using macosx)

I don't have that warning, I do have trackback though

I honestly have no idea about osx :(

Mineo, I'm not sure it's an osx problem, but I can make one mp3 available to someone who's interested :-)

huh, google decided to give me the new google+ interface today. weird.

So now you can place your cat in front of the monitor and still see all the content! :p

using google apps is kind of weird, because they generally have slower rollouts of new features on set dates, and announce them in advance.

so they changed the top bar design on google sites a little while back - and now I have it in google+, but am getting it in other google properties next week.

we should do that on musicbrainz.

:p

It seems that's in the plans!

reoafk: change things on musicbrainz.org only for some people before rolling it out to everyone.

Oh

We do that

It's called beta.mb.org

yeah, but it shouldn't be called beta.mb.org.

Why? It's exactly what it is

no, beta runs a different git branch.

I mean, "only for some people, before everyone" is a beta

So that's what it should be called

it should all be part of the same code.

Why?

using what rearchitected configuration system? :P

(not saying it shouldn't, just trying to understand it :p)

or, put more simply: we have more important stuff to work on :P

ianmcorvidae: I certainly agree with that.

reoafk: the feature being present (but disabled) in code used by lots of users gives me more confidence that the feature didn't break something unrelated.

reoafk: I would have preferred all the cover art code to already be part of musicbrainz.org, but just disabled for most users.

warp: how would that work?

Would non-beta users be able to vote on the related edits?

reoafk: they wouldn't see them.

it's bug or feature of picard when use "Standartized artist names" it add "Artist feat. Artists", but if in MB was "Artist / Artist" then in tags would be "Artist; Artist"

yes of course it's cool, but woulb nice to have option to get standart names with original separation symbols

reoafk: anyawy, that requires very modular and versioned code, it would be hard to implement on current mb_server.

So, we definitely have better things to work on, yeah

:)

(although I can see the benefits, they seem marginal)

(or at least relatively so)

it just makes releasing something much less of a headache, because the software is already there on production.

a release is just flipping a switch.

and the actual work of removing old versions of code and publishing new versions of code is decoupled from when users see those changes.

you still have to update the code at some point, I don't think you're totally right on that

ianmcorvidae: yes, but you update it completely disabled. no-one sees it.

warp: sure, but if it breaks something unrelated, that switch still breaks things :)

ianmcorvidae: then you enable it for yourself, do a few tests, then enable it for the group of beta users.

anyway, at the moment our policy is usually "merge everything into master just before release" (or just during, last release :P)

cleaning out my bf's CDs and I find this: http://www.amazon.com/Folksongs-From-Bavaria-Gr...

ianmcorvidae: yeah, so you need to have good test coverage, and easy ways to deploy and rollback releases.

until that changes, this makes no difference: we need to be actually putting things on beta before beta-oriented improvements to the way our code works are valuable :P

demosdemon: amazing cover

yeah!

It needs to get added to MB… stack for later

:)

ianmcorvidae: were you the one who messed with Etags or something on the webservice?

warp: yes, I enabled those

in the silliest possible way, but :P

why do you ask?

ianmcorvidae: I'm pondering the editable webservice, and we probably need something similar there.

I mean, etags are for caching responses -- you definitely don't want to cache responses for things that change data :P

let's say the editable webservice allows you to change things with a PUT request to /ws/2/entity/{mbid}

PUT should be idempotent, so the request body should have the full entity, with any changes to be made.

but if someone else changed the entity in the meantime, the request should be rejected so the client can re-request the document, make the changes, and submit again.

oh, hm

that's related, I guess -- some sort of wrapper around the full entity in the request that includes a hash of the base data?

now, the situation here is a bit different because the GET request associated with the PUT should have in some fashion a standardized set of inc= arguments.

well, it makes the combinatorics a lot less obnoxious at least :P

so perhaps it's ok to hash that and have the client submit the hash of the original document along with the PUT request. but still, meh.

easier to do it with dates

but then we have to be able to track dates :P

(obviously ocharles' fancy new edit system will make all this much easier :)

heh, I wouldn't necessarily count on that :P

(or count on that appearing anytime soon)

ianmcorvidae: I was also considering only submitting changes in the edit request (which would probably be POST then), but it's hard to described deletes that way

yeah

so then the problem basically becomes the problem of looking for a good XML diff spec, afaik none of those existed last time I was looking for one.

you still need some way to specify the base of the diff, I guess, so :)

ah, yeah.

so blegh.

mmkday… I don't know german

there's no way I can add that cd

Mineo, you around?

If you are ^

you're essentially trying to implement MVCC, seems like, but perhaps with hashes rather than transaction IDs

(or, timestamps, but)

however, it may be that /ws/2 is a poor choice of base for this sort of thing, due to the complexity of ?inc

not sure if we can do better though :/

ianmcorvidae: I'm not saying we should support ?inc= in the editable webservice.

no, but ?inc= in the current webservice complicates choosing this sort of a base-object for the editable WS

Artist: Lydia Und Ihre Munchner Buam

is that two?

ianmcorvidae: right, but we can allow that for requests, but not allow the output of anything which has used ?inc= as a document suitable for editing.

demosdemon: "Buam" seems to be some kind of "band" or "ensemble" word

warp: heh, if you can't do anything with ?inc there's not much you're going to be able to edit :P

ah

and I agree with kepstin

demosdemon: it's like "foo and his orchestra"

I've been meaning to poke around at trying to design such a thing

might as well throw on json output as well, make it easier to use from javascript.

except I never have enough time for anything :P

ianmcorvidae: e.g. let's say we define /ws/2/{entity}/{mbid}/?for_edit=true to be the same as whatever inc arguments are listed on the details tab for such an entity on musicbrainz.org.

just in a bavarian dialect that's nearly not even german anymore :P

ianmcorvidae: only those requests will come with a hash which the client should submit in the request headers along with its changes to the document.

warp: ah, so you're not saying that "no ?inc" is the base, you're saying that there's some predetermined set of inc arguments that provides a base?

ianmcorvidae: yes

Of course, of all the things to find in this library not in mb, it had to be in Bavarian

I still think I like kepstin's idea more, but that does seem reasonable

demosdemon: if you give me a minute I can give you a tracklist with correct capitalization :)

adding another WS is fairly drastic, too :P

kepstin-laptop: my prototype code on this topic does json.

I have the jewel case too

ianmcorvidae: I think it makes sense to experiment in the /ws/2/ namespace as long as possible, so that when we do need to go to /ws/3/ we've learned as much as we can from all the mistakes we've already made :)

warp: yeah, indeed; I was thinking of experimenting in the .mbsandbox.org namespace ;)