#musicbrainz-devel

hello!

navap: Does Cubby really give unlimited storage? At what cost?

yay, working desktop again

:)

arch?

yea

somewhat annoyingly banshee segfaults when I import my music :(

VLC :

*:p

Who wants libraries

vlc is terrible here.

Or rather, who wants underachieving libraries... kepstin-work, finsih Riker :p

i'm installing quodlibet for now

*finish

warp: terrible how? it's relatively lightweight and if you drop some files in it will play them

that's not really how I like to manage my music :)

reosarevok: I'm not sure. the sound is often stuttery or broken.

warp: what port is git.musicbrainz.org for writing again?

10015?

reosarevok: I expect it's not buffering enough so that it cannot read the file fast enough when something else is doing stuff with the USB disk.

originssh://mbgitrw [at git.musicbrainz.org]:10015/musicbrainz-server.git (fetch)

originssh://mbgitrw [at git.musicbrainz.org]:10015/musicbrainz-server.git (push)

thanks

ocharles: it's not how I would ideally manage it either

But library players are so depressing when you consistently use MB

reosarevok: maybe I can tweak it somewhere, but vlc also doesn't do gapless, so I haven't cared enouh to look into it.

It's like "oh, great, I have so much info... oh, you can't use 90% of it? sweeet"

So I've gone back to letting Picard manage my "library" by folders

I manage it manually (picard cannot move folders, so cannot do this for me)

ocharles: http://wiki.musicbrainz.org/User:kuno/Web_Servi...

warp: artist.aliases should be an array

(of objects)

oh yes. I do have that elsewhere.

yea

in the next example it is :)

I'm not so sure about the artist objects in artist credits

they do not have the same schema as other artist objects

why don't they have the same schema?

in artist objects, omission of certain properties implies they are null, but in artist credits it implies we're just not showing you that data (but it might not be null)

right?

hm, I don't think our XML is very clear about that.

in general our XML omits stuff you didn't request

oh, this is just to be the same as /ws/2/

i guess it's ok then

so the distinction between omitted and null isn't clear in our XML either. is there even a distinction? :)

no

Hmm

Do we actually have null ACs?

reosarevok: properties of artists can be null. e.g. not every artist has a disambig comment.

Sure, but then surely if it does have one we'd show it?

reosarevok: in the webservice, not quite.

Why shouldn't we?

(if I'm making very silly questions, stop me :) )

reosarevok: for example, a release has mediums with tracklists with tracks with recordings

reosarevok: but if you request http://musicbrainz.org/ws/2/release/59211ea4-ff... , you won't see any of that in the output.

reosarevok: just that something is missing from the webservice output doesn't mean the value is null or empty in the database.

Ok, I guess my point was more "we either show them all, and then if we don't it's not there, or show none, and then none are shown"

(but it'd be quite confusing if we showed some but not some others of the same thing with the same query)

reosarevok: in general the output of the webservice is somewhat tailored for specific use cases, and information we didn't think was relevant is omitted by default to save bandwidth.

reosarevok: and that's why you can do ?inc=foo to make the server include those things which you think are relevant.

Sure, but then, if we just don't include something, there's no possible confusion so why does it matter?

reosarevok: well, the confusion is then that the client who gets to interpret the webservice response can never know if something was merely omitted from the results or if it is actually null in the database.

But reasonably enough, if it cares it should actually query for it?

yes, so you when you write your code to interpret the results, you have to take into account whether certain bits of data or normally included with the type of request you did.

So, the JSON doesn't need to take this into account, the documentation does

And to avoid it being unclear it just needs clear documentation

That's what I read from this :)

I'd be in favour of just Doing It Right

For ws/3? :p

so that e.g. if an artist doesn't have a disambig comment, we include "disambiguation": null

Oh, that sounds reasonable, yes

new schema doesn't allow null for disambiguation, but that's an aside :)

so that if the "disambiguation" key is missing you know that the server omitted it.

warp: NES

ah, so disambig is just "" then?

yea

seems... odd.

NULL does not mean absent

it means unknown

but we know that this artist has an empty comment

oh, right. you are correct.

same why a null joinphrase is a bit funky

(and has caused us problems)

ocharles: any other comments on /Web_Service/JSON ?

warp: i haven't quite looked in detail yet, but nothing stands out as wrong

do you think it's ok to make the relations one list?

yea, i don't see why not

it's seperate in the xml, but that just seemed annoying to me :)

ocharles: ok, thanks for taking a look. I'll post it to mb-devel.

ocharles, warp: should we make this impossible, or do we agree it's fun enough to keep? http://musicbrainz.org/user/nikki

(age)

my original ticket description said max age of 100 at that time

Sure

so i was surprised when nikki was allowed to do that

this is way under 100 :p

oh right

yes, your date of birth should not be greater than now()

I guess it doesn't necessarily matter unless we start graphing them, though

data integrity matters to me, regardless of where it is :)

:p

Fiiiine

nikki, when you read this, blame ocharles :p

all it takes is someone later to say "oh, I'll compute x!" and they suddenly are showing wrong data

more often than not, you won't realise until it's infected more of your data

Also, http://mb.lmfao.org.uk/editorgender

This is what happens when our 3 main female editors don't set their gender :p

I guess the graphs should have an "unset" option

I guess it's kinda public data

oh wait, we dump editor names anyway, so this seems fine

ignore me :)

I wouldn't be against limiting the data in the dumped editor table to only names, too

(or well, the bare minimum for it to import)

indeed!

can you ticket that?

ocharles: http://tickets.musicbrainz.org/browse/MBS-4975 is one

thanks

reosarevok has changed the topic to: http://musicbrainz.org/#devel | Agenda: text column constraints (ocharles), editor data in dumps (reotab)

And that's the other

:)

(since the rest is public on the site so we should discuss whether we want it or not)

Tsk

Apparently we have 27 people who are 27

reosarevok: I don't have much of an opinion. it seems odd to me that we show age at all.

Why? It's nice to have an idea of who is behind the username

reosarevok: I don't think there's much of a problem with dumping birth dates.

alright, time to get myself to Bloc weekend

it will take someone a year to determine the exact birth date from the age we show.

see you all on monday!

so a determined person will be able to get the birth date from the age.

ocharles: enjoy!

warp: sure. so?