#musicbrainz-devel

it's only a month away, I can live with that

I'm sorry we can't make everything perfect at once, ocharles.

ijabz: I spent time on the ticket in question

jira tickets, nikki !

and trying to fit that into our current constraints spent more time than the naive solution

We have an Anonymous Jira user, which both nikki and me see no real point for

Apart from avoiding us from contacting ticket reporters

I mean, someone's apparently even been voting on tickets with it

we also have one weird person who keeps using the anonymous user to watch and vote on tickets

we have a large community of people submitting bug reports on jira, so I expect most bugs will be reported if we disable anonymous.

(at least one :p)

+still

so I'm ok with disabling anonymous.

I'm ok with nuking that account.

I don't like that people have to create a second account to report stuff, but since anonymous tickets mean we can't contact people, it makes those tickets hard to deal with

nikki, reosarevok: I assume one of you has enough admin power to disable it?

I see a delete link

not sure if it works :P

:D

one way to find out.

onward to NES, ocharles!

ok, just a wrap up topic to see where we stand on this; what to do next, etc

i personally have been researching how the granularity plays in haskell, and it lends itself to some interesting graph reduction problems, but that's not very relevant :)

i see you added a few comments in the doc, but are we happy with the questions and answers in that doc?

yes, for now.

the main point that I think we need to address now is the client perspective for the tiny granularity.

hmm, this is just data access though

it doesn't affect clients at all

I think it does.

ruaok: this is not the webservice. so you're have ijabz search server hat, not the jaikoz hat.

i think it does in an insidious way

only if we wrote /ws/3 at the same time

yay english

for me, ws/3 might just be a thin layer around the data access stuff.

i still worry about doing data access/nes and /ws/3 at once

and the data access layer will push how the ws/3 is done

i don't think

I'm not suggesting that we do that.

so

it's so granular you can easily compass into something much monolithic, if you want

but you can't go backwards, hence me advocating granularity where possible

ruaok: ok, cool

but I am suggesting that we think about it now.

ocharles: I haven't had a chance to look at the doc since I returned.

so working on it, but only as far as "let's try to not make the data layer break immediately when we try to do /ws/3" ?

did you have any comments on my "make as many requests as you want, wait for results from the server async" approach?

ianmcorvidae: sure, that is one way of looking at it.

that's actually part of what i've been working on currently, though not quite with that question in mind

I have a prototype where you can describe a graph of queries, and hand it to an engine which figures out what can be run in parallel, what can be aggregated, and so on

this was mostly for fun, but maybe it does actually relate to that

ocharles: is it async?

not designed with that in mind yet

because it wasn't designed for a client, but more controllers before rendering templates

ah.

can you think about it in the context of clients?

async doesn't make sense for a web service, because there's no way for a server to initate a connection to a client.

I would love to bring the granularity to all levels of data access.

i would, but not now. I'd like to just have /ws/2 talk to this and act exactly the same

kepstin-work: it could push results back on the existing channel when they become available.

kepstin-work: web sockets :)

warp: I suppose, but then you need to add more complicated framing and request ids to id

ruaok: really to think about this from a client side does mean I need to think about /ws/3 a lot more

ocharles: I would like that.

i can do that if you want me to, but we're juggling a lot of abstractions around as it is

we didn't do enough future proofing when we did ws/2.

Be nice if you could write down clearly the advantages of granularity, as its still a vague concept to me

and this data abstraction will impact a lot of things.

so, it would be nice if we can think more down the road to consider the changes that might come.

ok, so this comes back to the data access problem - what questions am I answering? :)

ijabz: I think you understand (and hate it) quite clearly. :)

do we want a schema for /ws/3? a map of end points?

What i don't understand is why everyone seems to think its going to solve a load of problems, I see it only solving one

ocharles: the question to answer is how a client can live with a system where they need to make a lot of more calls to fetch the data.

because inside of the current ws/2 model that concept is pure insanity.

ruaok: there are various answers, but they all depend on an implementation

of course they do.

ie: make parallel requests and have a good library to glue it together, remove/reduce the rate limit, use web sockets to stream stuff

then lets outline the various answers so we can consider them.

I mostly like the idea of submitting a query tree to the server and having it inflate it at the moment

but that's not very RESTy

Surely making parallel requests is circumventing rate limiting ectera

and maybe REST needs to go. I don't know.

well, a 1/s ratelimit makes no sense at all with a granular webservice

note: I haven't deleted the user, but I have changed the password and removed the references to it on the login screen (apparently deleting it will make the comments attached to it a bit weird and then someone could just go and recreate it)

we aren't very RESTful right now, in fairness

right now we have apps all making /massive/ queries with lots of inc= to workaround the ratelimit

ianmcorvidae: and I think us trying to be restful is making our lives harder.

I wish I wash't the only paying user seemingly bothered to get involved in this discussion

ijabz: you're not.

I personally am representing your side in this.

I think we need to either be more strictly REST about it or drop it entirely, yes

I think "trying to be restful" isn't really the problem so much as "not really doing REST, but some weird perversion of it"

haha

we're struggling to fit our data into the REST model and it doesn't work well like that.

i don't think we are

we're mapping documents to a graph.

and that is really ugly.

because we never designed how it would look with REST

a more granual model would make it fit better with REST though

granular

warp: it would.

yeah, granularity is a lot more RESTful

well, we just need to make the stuff returned from a request include hyperlinks to linked data in the graph, rather than including the data itself

but the HTTP RESTful way of doing will drive clients insane.

(in the membrane)

and some of the "but we need so many different URLs!" problem gets solved by being RESTful by using hyperlinks

obviously the ratelimit needs help, but I suspect that's true *whatever* we do

bad time to disconnect, Why don't we we create a document that clearly lists all the problems with ws/2 and then see what solutions we can come up with

so, really, I think we need to consider all of our options on this front before we proceed with data access layer work.

ideally, using smaller simpler queries that are easier to cache would allow the ratelimit to be increased.

kepstin-work: sure.

the ratelimit just needs to be tweaked so a fetching full release in picard/jaikoz doesn't take longer than it does for /ws/2. so the amount of data recieved / time should stay constant.

but the overhead of making an HTTP call becomes very great at that point.

ijabz_: that's the idea with asking to list options so we can consider them, I think -- but agreed

not the best use of resources/time

ianmcorvidae:might have missed that offline

so for the next week, what am I doing?

ijabz_: fair enough -- ruaok is wanting a document that explores possible solutions; I think what you're saying needs to be part of that :)

warp: i disagree. HTTP call overhead is a problem.

i'm hearing a lot of general worries here, but nothing I can specifically focus on

ruaok: ok, a valid criticsm :)

ok, I can take a stab at creating this document.

!

listing existing issues so we can enumerate them.

please share it around again, it worked great last time

ok, will do.

ijabz added a lot of great questions

shall we triage some bugs today?

sure

I can try to be the super-pedantic-about-REST voice for you :)

ianmcorvidae: please do that!

ianmcorvidae: i have that base covered too :)

ha, already read it

lol, ocharles wins.

hah, yes

ocharles: bug triage?

I mostly volunteered to make myself read the damn thing :)

i'm not sure how much time i have

I just read the o'reilly books on the topic.

I can triage for a bit of others want to

you're welcome to go ahead and i'll leave when i'm not free

ok, lets close.

thanks for your time everyone.

lets triage, starting right now.

thank you ruaok