#musicbrainz-devel

laser* :)

unless we're talking about light amplification by zimulated emission of radiation, which sounds like a crazy german professor's invention... so it could be!

wut? its not musicbrains, afterall. :)

*itz

:D

:)

ffffffffffffffuuuu. http://www.reddit.com/r/compsci/comments/18gvkl...

my ivory tower needs to come equip with rocket launchers. there is far too much wrong on the internet today

alas, time to sleep

ocharles: You can't!

ocharles: Remember https://xkcd.com/386/ !

No sleeping after you discovered someone being wrong! D:

oh yea, dems da rules

I also learned today that XKCD comics have a <div id="transcript" style="display: none"> with a transcript of the comic.

That's... awesome.

freso: that's necessary to be indexed by text in google ;-)

JonnyJD: Sure.

JonnyJD: But you don't need to repeat the title/hover text of the image.

JonnyJD: Etc.

right

maybe that is better for screenreaders

That's what I was thinking.

and supporting that really IS better than just trying to get indexed by google. But I have no clue about any standards for this.

One my personal SEO tenets is to make stuff as accessible as possible.

The easier it is for people with "special needs" to read the page, the easier it will likely be for search engines etc. too.

This here being a good case for that. :)

Disable all CSS and images, and you will still be able to "get" the comic.

ianmcorvidae: the 1099 is in the mail. try not to laugh at the handwriting. :)

I found http://www.w3.org/TR/WCAG20/ and http://webaim.org/standards/508/checklist but I couldn't find a "transcript" id.

Do they have accessibility guidelines specific for web comics though? :)

http://www.w3.org/TR/WCAG20/#text-equiv " Guideline 1.1 Text Alternatives: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language."

That seems to cover it pretty well. :)

logically: yes. I was looking for some kind of syntax/api/naming scheme for that

but maybe there is no such thing

I don't think there is.

The closest thing would be to include it in the alt="" element.

But I guess you quickly enter into browser compatibility issues with that, if you wish to support older versions of a certain browser, which IIRC didn't deal well with alt attributes more than a certain length. (Given how some XKCD comics can be somewhat long-ish.)

and you probably don't want the whole description to fill the screen when your mouse lands on the image

Well, that should be the title attribute used for that. :)

(Which he's also using as part of the comic itself.)

But old(er) browsers may have different behaviour.

oh right, that's the title. I seem to have forgotten that in the last years.. I am sure I checked that at some time

oh well, time to go to bed

It's not good for me to have tatl back in function. :|

* Ian McEwen: MBS-5759: make 'Reorder Cover Art' an autoedit

* Ian McEwen: MBS-5520: remove extra level of indirection for some links whose text needs to be translated along with their containing string

* Ian McEwen: Update mb_server.pot

* Ian McEwen: Update translations from transifex.

apparently I suck at writing non-test-breaking patches lately

(it's running again though :P)

Ian McEwen: MBS-5759: add proper includes to unbreak tests

or not :P

Ian McEwen: MBS-5520: Escape dollar sign in template to unbreak tests.

hello!

bah, 3scale's docs are not what I'd like them to be :/

well, really, it's more that they have a bunch of mutually-incompatible options for doing what should be the same thing

you can use a language plugin, varnish, or nginx -- each language's plugin has a different set of features actually implemented, the varnish plugin has a different set, and the nginx stuff seems to be yet another set

and most of this you can only find out by reading the code!

of course, the specific thing I was hoping to do appears to be available only (in the places I've deciphered enough to find out) in the PHP language plugin

(so neither the perl nor the varnish options -- haven't figured out how the nginx thing works at all yet, though I know it uses nginx features we don't have, so we'd have to replace our nginx on the frontends...)

</rant>

ianmcorvidae: sounds fun.

heh, something like that :)

ianmcorvidae: how complicated are those plugins?

the varnish one is not something I'd be fond of dissecting, especially since it's in C, which I don't really know

knowing C doesn't make dissecting any more fun :)

the perl one is very straightforward and could probably be extended to do what I want, but I'm not sure about writing more perl or if that's the proper place to be doing things (especially since it might make caching of responses less than possible)

well, it possibly makes it at least more plausible as a route forward :)

my thinking is I may just see if I can interact with a real person at some point

the basic issue is that, at present, the varnish stuff is basically written such that we would only be able to know "they're authorized" vs. "they're not authorized", which means we could only have one sort of plan, which seems like bad forward-thinking :)

it doesn't come with any sort of identifier of who is being authorized?

it would pass along an application ID, but without another query to them from the perl (meaning we request from them twice per request) we don't know what plan that corresponds to

the authorize/report endpoint we're using does return the plan, but it doesn't seem to be available via the 3scale plugin at all

though, hm, I may be able to pass along the entire XML response from the authrep endpoint

wonder if there's a character length on HTTP headers

limit*

ianmcorvidae: i'm also thinking how this ties into more flexible rate limiting for non-paying (but authenticated) webservice clients

I think some of my other changes will help there

we're moving more of that logic to the ratelimiter -- so mb-server just passes along some basic info (what's being requested, what IP they're requesting from, what user-agent, 3scale information) and the ratelimiter decides what keys to use

ianmcorvidae: ok. if customers paying for webservice access want to be authenticated on musicbrainz, do they seperately authenticate to 3scale and MB, or is that just not supported, or something else?

so, they sign up for an account (semi-fuzzy what sort of account that is, at present, though I think what we're doing is treating everyone as an "app developer") with 3scale

then, when they request from us, they put on some X-whatever headers to pass along their info, which we then use to query 3scale

where what we're asking 3scale is basically "hey, who is this key/application ID, are they paid up, and what bucket do they go in?"

ah, ok

user auth for MB itself just works as usual

and then obviously anything without the X- headers just gets put in the global/normal bucket

with the current thing we can't get the "who is this" or "which bucket" answers, and there's no distinguishing "they're not paid up" from "they didn't try to authenticate"

not sure the second distinction matters, but if we want to have, say, a user-level tier and a commercial tier, we need the first :/

our ratelimiter is currently perl? are we moving that to something else?

it's currently perl, I don't know if we have plans to move it

I certainly don't see much need to rewrite it, I guess

so the varnish/nginx plugin which pings 3scale would just set additional headers for the ratelimiter to act on, correct?

yeah -- at present it just keeps the app ID/app key headers intact if the authorization works, and removes them if it doesn't

but ideally, I think, it should set an X-3scale-plan (or something) header as well

and obviously mbserver needs to pass along those headers to the ratelimiter, but that part's easy

I think I would prefer that functionality to be part of the ratelimiter itself, that would focus all the ratelimiting bits in one place.

and if we care about distinguishing "not paid up" from "didn't authenticate", it should never remove headers, but add some sort of X-3scale-authorized header (obviously all names are completely non-final)

hm

as in, pass everything through the whole way, and have the ratelimiter do the ping to 3scale?

but then it seems almost a requirement to re-implement the ratelimiter in something faster/better, like nodejs or haskell.

ianmcorvidae: yes.

ianmcorvidae: well, I imagine nginx pinging the ratelimiter, not mbserver.

ah -- that's not how it currently works

I know :)

mbserver / the search server are what call out to the ratelimiter :)

heh

sure, but that seems wrong. if someone is going to be denied access because they're over the limit, that shouldn't touch mbserver.

that may actually basically be what their nginx thing does -- I know it requires the Lua plugin, so

but 'over the limit' is more than just what 3scale thinks, because we have non-paying clients which need to be limited in various ways too.

except their nginx thing assumes you're using 3scale's ratelimiting, which we aren't since not everything will need to hit them at all

still, that may be the way to go -- move the ratelimiter to be lua code running in lenny/carl's nginx

yeah, exactly

that's what I mean by "their thing assumes you're using 3scale's ratelimiting"

well, lua is just the way that it can just be part of nginx directly

yes, I know :)

afaik nginx basically only has perl and lua integrated modules, so given *those* choices, lua :)

I do like the workflow that creates: if something will be denied, it gets denied early in the process; updating ratelimiter configuration mostly just requires a HUP to nginx

sure. so I wouldn't pick nginx for that part, because I don't want write perl, lua or C.

yeah; I don't know how well nginx supports querying a separate service for something like this

which I think may be part of why it's not currently done with nginx being the step that calls the ratelimiter

(it's possible that the only way to get nginx to make an HTTP request in that way is to use Lua anyway)

(er, well, HTTP or UDP or whatever)

hm? that shouldn't be too hard

I think you can use the regal fallback stuff.

not quite sure what you mean -- I don't know a way to have nginx do something like "query this endpoint, and depending on the response either return 503/429 or proxy to <load-balanced upstream>"

I could be wrong, my experience with nginx is limited, what I'm thinking of is:

something like location / { proxy_pass http://ratelimiter; error_page 420 = @denied; error_page 204 = @musicbrainz_server; }

oh, hm, that's true, that may work

oh I guess the OK status needs to be a 4xx as well (ref: http://wiki.nginx.org/HttpProxyModule#proxy_int... )

I'll read up on nginx @location stuff

yeah, but we can use whatever 4xx code we want, it's all internal

I propose our "okay" one be HTTP 418 I'm a teapot

:P

:D

ianmcorvidae: I think we should also discuss how we want to implement rate-limiting headers (like on github and such) soonish.

hm?

oh, as in for adaptive ratelimiting

yes.