#musicbrainz

but not, really, MusicDNS will be around at least for a few years

there are paying contracts that will keep it live

it would be stupid to shut it down if it produces money

not bad at all, leaves enough time to test alternatives

does it being live imply MB can still use it for free?

yes, because nobody cares about it

too little traffic?

probably not, but as long as it's not only MB, it's probably worth it to keep it alive

note that MusicDNS itself has not been sold, only the IP

Weren't they supposed to pay $10k or some amount to MusicBrainz when they stop the service?

that's complicated, MB would get the code, but wouldn't be able to run it because of the patents :)

I started thinking of a way to make PUIDs useful ever after MusicDNS is dead

I'm going to try to map as many PUIDs as possible to Acoustid fingerprints

Ah here we go. http://blog.musicbrainz.org/?p=160

"$10,000 held in escrow for MusicBrainz, plus contractual commitment to supply hardware resources should MusicIP exit the fingerprinting business. This is designed to allow us to continue the service should they decide to stop providing the service."

So is this still in effect?

yes

technically

:/

why just technically?

because it's not sure what will really happen

maybe because we don't have lawyers...

oh, hi hrglgrmpf

nikki: hi :-)

really? what exactly?

good question :P probably recording comments

ah yes, I will change them once they are applied

if something is unfinished, I put it in my "TODO" collection, so I won't forget it :-)

I mark the emails as unread even though I've read them, but I'm usually slow at replying to emails or edit notes

nikki: what do you think about server-side URL cleanup?

since you are very active cleaning them up, you must have a profound opinion of it...

hmm... I'm actually more curious about why some urls don't get cleaned up even though the user has js on

I have to use ctrl-v (not the mouse), otherwise the JS isn't triggered

I don't really have much of an opinion about doing it server side though, for the most part it's things that aren't even being done in js

or fixing things that are hard to do programmatically, like fixing or removing wikipedia's damned 404s

I'm talking about the server-side validation ticket... I always thought the MB approach is: better the user enters a malformed URL, than nothing, it can be cleaned up later

that would mean the ticket should be closed as invalid probably...

but server-side cleanup for e.g. ASINs, allmusic etc. would be very simple and effective

I have to wonder if there are that many urls which slip through that we should spend time adding it in the server too though

btw, if you know how to reproduce it not working with the mouse, please do report it

possibly we should just run the JS callback thing on more things

probably not...

I guess we're not checking for everything

it currently runs on change and keyup

ianmcorvidae: yes

well, or, after we set the value we should do .blur() or something, I forget how that works

.blur()?

blur is triggered when something loses focus

and I know that for me the value of the field doesn't actually change until I click into the edit note field

i.e. when a blur event is fired :)

so possibly triggering a blur event would make it work more correctly

ah, so it doesn't make it blur it

yeah

it does 'self.urlControl.val(clean)'

nikki: I think I was wrong... if I paste with the mouse, the link doesn't get corrected, but clicking "Enter edit" (or return) afterwards does... so I don't have a explanation...

something like self.urlControl.val(clean).blur(); might fix it

hrglgrmpf: if you paste in and then click into the edit note field, what happens?

ianmcorvidae: nothing

ianmcorvidae: no correction

oh, it doesn't unfocus it, it just triggers the event that unfocusing would trigger

if that makes sense

yeah, just saying :)

it triggers a blur event without you actually having to unfocus it

ianmcorvidae: argh, sorry, I misread: clicking in the "Edit note" field cleans up the URL, but clicking in the URL field doesn't

okay, cool

I think triggering a blur may fix hrglgrmpf's problem too then

but it cleans it up when you press enter/return?

hitting enter selects the "enter edit" button, deselecting the url field, triggering a blur event :)

something's not working somewhere at some point though

and I seem to have seen more urls needing cleaning up since ngs came out

hm

and kepstin managed to enter an amazon url twice that didn't get cleaned up

(and when he asked, he said he has js on)

hm

I'm having trouble figuring out what exactly happens when http:// isn't included

it looks like maybe it doesn't run cleanup when that's not there?

I thought it wouldn't accept it without that

at least on the live server

well, yeah

so the urlChanged trigger checks, first: url.match(/^\w+\./)

if that hits (i.e. there's no http, although it's a convoluted way of saying it)

then it adds http:// to the front of the url in the value and returns

that was added recently though

if that _doesn't_ match then it goes on and uses the cleaned value, if applicable

so what I'm not sure is if the self.urlControl.val('http://' + url) would trigger a change event, and thus cause urlChanged to get run a second time

I tried on test and it added the http:// immediately, then fixed the url when I submitted it

yeah

perhaps compile a list of un-corrected URLs and we can see if there's a pattern there?

:o

I did it!

ooh

how?

*and* I finally got that fly that's been annoying me for hours

I used cmd-v to paste www.amazon.co.jp/dp/tracks/B0000AFOPB/ref=dp_tr... and hit enter really quickly

if you hit enter more slowly does it correct it, or?

it seems so

hm, no

it seems I just need to click in the field, paste, press enter, and most of the time the page submits before the js finishes

hm

that suggests that hitting submit should fire the url cleanup thing

or something like that

but if I paste http://www.amazon.co.jp/dp/tracks/B0000AFOPB/re... it works fine :/

it does

but it finishes submitting before the field updates

oh I think I see what's going on

without the http:// the urlChanged thing has to fire twice

so it fires once, and then your submit fires before it can hit it a second time

yeah

whereas if the http is there it only has to fire once, so it happens before the submit

bwahaha

what this says to me is

instead of changing the value and returning, it should change the url within the function and then clean

i.e. don't have two different paths by which it sets the value

I can reproduce it with http:// if I use the mouse to drag selected text into the box and then hit enter

hm

that's even with the http:// there?

which I suppose is the closest I can get to middle-click paste without opening my vm

yep

oh, it is open

that's handy

hm

potentially you should litter your root/static/scripts/edit/MB/Control/URLCleanup.js with console.log to see what's getting fired when

(well, and how many times, with what URLs, etc)

er, opera doesn't have console.log, it has something else

but still

yay!

middle click paste + enter