#musicbrainz-devel

re: types of coverart, would it be prudent to make some simple images ilustrating wich part of the cd/vinyl etc each "type" is supposed to be? eg spine, [image of a jewelcase with cd goes here, but the part that is the inner is redoutline/solid some colour] ?

erh spine/iner or iner/spine as apropriate

CatCat: once we've figured out what they actually mean :)

cool

natta

that doesn't look like someone who doesn't know what he's doing.

you should submit that to codereview.musicbrainz.org

nah, it's the first time I've used perl, so I was really just copying+pasting random things until they worked ;)

but I'll add it to code review

Don't worry, bitmap. That's how people who know what they're doing in Perl do it.

lol

warp, I don't know how much work this would be: http://tickets.musicbrainz.org/browse/MBS-3604

But if it is a short fix, please try to fit it in your next CI somehow

Newbies get *VERY* confused

ocharles, your last comment in http://tickets.musicbrainz.org/browse/MBS-2079 makes sense to me

I mean, not the most obvious UI ever, but definitely better than what we have and probably the option that offers more customisation possibilities

whatever works

just implement *something* :P

I mean, "would this be a too obscure interface"

But...

obscure interfaces are something people can at least learn to use

missing interfaces are unusable on account of them being missing :P

Ok

ocharles, go implement that! ;)

(pretty please)

Hi voiceinsideyou!

What do you think of the idea ocharles presented on hist last comment at http://tickets.musicbrainz.org/browse/MBS-2079 ? :)

nikki said "obscure interfaces are something people can at least learn to use, missing interfaces are unusable on account of them being missing :P" and I tend to agree

Back later!

reosarevok: I'm not really sure. I'd tend to agree with nikki; assuming it's obscure, rather than buggy - to put it bluntly :)

well right now people ask how to do it and we have to say you can't

Well, that depends on how it is implemented, the question is whether we want it to be like that

Indeed.

Obviously whatever we do, we won't want it to be buggy

whereas if we have a way to do it that's not obvious, we can write an explanation and point people to it when they ask

(meh, 502: http://musicbrainz.org/edit/relationship/create...)

(it worked though)

Well the current situation is that the release editor is so ridden with bugs and 502s that I'm not personally willing to push for any features at all :)

well ollie would be doing the relationships stuff, kuno does the release editor

voiceinsideyou, this would be outside the RE as far as I understood

Oh, you mean because you want that to be fixed

Yeah, that's warp vs ocharles

TSK

More 502

yea

What is going on?

Indeed. Who does what is of course a decision for the team; but I guess I personally see this specialization as a bit arbitrary (although obviously some people are better than others at JS) when we have this burning fire of an RE

:)

i just got a 502 on reo's link too; it was a "quick 502" which IIRC ruaok indicated the other day was probably due to something wrong with nginx or that layer, rather than the server

(as opposed to RE 502s, which are generally slow ones - server failed to respond quickly enough, etc)

and another...

me too same time

and a bunch more...

http://musicbrainz.org/work/e16e4dde-5639-4ec0-... for me

it's just random pages for me

yeah, me too; just putting URIs down for the record in case anyone decides to go back through logs :)

uhhh

<3 the release editor

(with much sarcasm)

voiceinsideyou: does http://pastebin.com/Hzq7S3Jg look familiar to you?

morning!

502s gallore still?

on and off

nikki: looks like a session timeout of some description?

how nice of it

I got about 6 tracks in and decided to go to the next tab to stop it from timing out, only for it to crash on me and lose my stuff anyway

however, given the frequency of timeouts (and people logging tickets recently), I have grown suspicious that there is something else going on

ocharles: btw you said last week that you would post on the style list about inheritance yesterday :P

i said I'd do it on my monday? I thought I just said it was on my todo list :P

still haven't got a 200, curse you blasted bug tracker!

hello!

g'morn

ocharles: I'd like your opinion on HTTP status codes again.

sure

ocharles: "202 Accepted" seems a suitable response to a PUT request to change an entity

And returning a pointer to the edit?

(asynchronous processing, location is supposed to point something informational about the processing taking place)

ocharles: yes.

sounds fine to me

ocharles: but what should the status be if a NoChanges exception is thrown server side?

"304 Not Modified" seems to map well, but is only supposed to be used at the HTTP level, with "If-Modified-Since" headers and such.

in a sense it is an error (4xx), because the edit wasn't created. but it's also success (2xx), because the entity has already been changed in the way the PUT was trying to change it.

hrm

I don't think it's right to use 304

so that only seems to leave 409?

I was leaning towards 409 for error yes.

but I was also thinking of 204 or 205 to indicate, look dude, it's already like this, success!

Well, currently in the form when you try and submit with no changes, you don't leave the page

ok, 409 is closer to that.

But where are you going to display a message saying it hasn't changed?

yes, a 409 response probably can have a body.

so $serializer->output_error ("bla bla no changes blah")

sure, but we said it should have the body you gave the request with information on each attribute with information on what's wrong

oh, right, I haven't done that at all yet.

In TreeValidator, cross-validation errors are put at the deepest node that contains all nodes that failed cross-validation

which in this case would mean an "errors" node under the root node (<label>)

I'd be ok with that

ok

and any kind of error (including nochanges) should be a 409?

well, we couldn't find any other appropriate codes last time we discussed this, iirc :)

er, any kind of validation error I mean. a parse error still is just a 400 or something.

yes, ok.

right

ocharles: where should validation go in our architecture?. it's obviously not going to be in the MusicBrainz::Server::Form::* anymore.

should that be part of the models, the entities, or have a seperate set of validator objects?

I'd prefer a separate set of objcets

ok

Effectively moving towards a factory pattern

"LabelFactory->create_label( %label_info_here)" yielding either a Label object, with certain attributes transformed (trim, whatever), or a set of errors

then you can create edits from that Label object

right, so the edits would also change (eventually) to just take old and new objects.

well, could, they don't need to