#musicbrainz-devel

so please if you have a minute to just check in that mmd change I could finish it off

nice, thats a good deal. :)

crap. I forgot to check that in. too damn sleepy last night.

np

comitted.

ruaok: ping

wail.

:)

do you want me to take some of the tasks you've got assigned to you for b1?

I'm feeling fairly confident my remaining tasks might not take what the estimate is

the direct search is a task that I may not get to.

Cd stubs are also not going to happen for b1, but that is not a big deal.

183?

no.

oh, 204?

yes.

cool, i'm going to give you a ship it on the external search then, and I'll take that issue

that involves changing Search.pm to load the data that indexed search provides.

perfect!

seems doable :)

the biggest issue there is writing another query for finding releases that belong to recordings.

thanks, much appreciated.

I need to spend an hour making sure error pages look a bit more presentable too

I'm glad that external search will go in. then I can focus on WS issues. :)

I'm making good progress on WS stuffs. The core is there, now its just time to pound out every last little nook and cranny.

acid2 what is 'External Search' ?

ijabz_: search.mb

ijabz_: what you and I have been working on.

indexed search.

we should actually do a nomenclature fix on that.

yea sorry, I need to stop calling it external

it should be indexed not direct.

s/direct/external/

oh

http://musicbrainz.homeip.net:3000/ws/2/recordi... :)

that was quick!

I nearly have all the base data of the core entities returning. search is esp quick. it ported real nice from the old version.

that hard part will be getting all the supporting information for these basic requests.

aCiD2: wrt to the minor ramifications, feel free to fix them outright when you work on direct search. or, send me mail and I'll clean up after b1

sure thing

nice to see the webservice working !

all the core entities but work are working. search and mbid access.

oh, and what is cool about this is that the table that defines all of the possible values for each call type can be used to automatically generate the core docs for the WS. :)

neat!

aCiD2: http://musicbrainz.homeip.net:3000/search?query...

see the num column.

the first value is the track number.

the value after the / is the medium number.

how do we best represent this in a sensical mannger.

do we need to present it?

at all?

hi

x / y is clearly unintutive.

hi nikki

<- kaputt

nikki: bed time or are you damaged goods?

long day with lots of train delays and cancellations

aCiD2: I think giving an indication as to what medium we're talking about is nice.

and we have the data at the ready.

nikki: where did you go?

ah, the medium number is interesting, true

is the snow still gripping .de?

i'm not sure you need to go any further than that

aCiD2: "track x on medium y" would be best.

aCiD2: Oh..lol that's what it is.

I've been trying to figure out what "5 / 1" mkeans.

I'm back at mum's, it's her birthday in a few days

another thought is to leave out medium number when its 1.

at my mum's, even

and only display when its non 1.

ruaok: right, but you don't have space for that

nikki: ah.

aCiD2: right.

so, now what. :)

and navap proves that this is a problem.

Personally, I think the clearest way to present it is to have a "Medium #" column, and just use the medium position value

oh duh.

acid2, agreed

readable, gives me enough information to make a decision 99% of the time

ok, done.

:)

Is the number of releases a recording is on important information?

no, I'd lose the Num and Tracks columns

this is just me though

navap: not in this context I think.

the tracks column is critical for tagging.

and the medium is really handy for letting the user pinpoint the track on the release view.

yes

Ok, in that case I'd do this:

Medium # | Track columns

and have x | y/z

x = medium number, y/z track number/total tracks on medium

that sounds fine to me.

navap, ijabz_?

I like condensing the number and tracks columns.

though I would swap the order of the two columns.

+1 on swap

i'm happy either way, swap away!

s/Tracks/Track/

refresh

perfect!

SO youre losing total tracks on release then

Can we switch from displaying a score out of 100 to a score out of 10?

And round to whole number.

ijabz_: we never had that, did we?

navap, the score is calculated out of 100

navap: we;ve been using 100.

acid should match the direct search to use 100 as well.

Sort using the 100 calulation, but display using an integer from 1-10

I don't think I ever know how many tracks on my releases, only mediums

navap: I'd like to keep 100.

But total was intended to be release total wasn;t it, i it just wasnt

ok, I'm happy.

ruaok: Okay.

I'm ready to commit this and return to WS work.

\º/

ruaok: Can you do something about the alignment of the tracks column?

do what?

1/4 and 13/15 end up aligned very differently.

Can you align the first number to the left and the second number to the right?

That will make it easier to read the numbers at a glance.

that's hell to do

if you give me the CSS/HTML, I'll do it.

well, not hell, but too much effort

:)

heh okay, let me see what I can do.

but sadly, I must return to the WS if I want to have a snowball's chance in hell to fix it by tomorrow afternoon.

Column needs to be wide enough to fit in xx/yy at least in one line

ruaok: get it pushed and then navap can patch it and I'll merge it back in :)

aCiD2: good plan

Yeah the track column needs to be at least 45px wide, maybe 46px.

To fix the xx/yy values.

code is committed.

woohoo

/home/robert/musicbrainz/mb_server-ngs-svn/script/../lib/MusicBrainz/Server/Controller/Search.pm line 107

I used your suggestion in the codereview, aCiD2

We don't have Model::Search.pm

yep