andrewxhill / MOL

The Map of Life
mol.colorado.edu/
19 stars 4 forks source link

New layers surface in stack right away #44

Closed eightysteele closed 13 years ago

eightysteele commented 13 years ago

So when you select a layer and click 'add', the layer widget should show immediately in the stack instead of after load.

andrewxhill commented 13 years ago

While you are in this area, there is a problem with Delete. If you load some layers. Then delete them. Then load more, the first set reappears.

Loading multiple point datasets at a time fails.

eightysteele commented 13 years ago

On it. On May 6, 2011 2:21 AM, "andrewxhill" < reply@reply.github.com> wrote:

While you are in this area, there is a problem with Delete. If you load some layers. Then delete them. Then load more, the first set reappears.

Loading multiple point datasets at a time fails.

Reply to this email directly or view it on GitHub: https://github.com/andrewxhill/MOL/issues/44#comment_1110334

eightysteele commented 13 years ago

So one thing... can we mod the points API to take a list of names to search on, instead of only one name? Thoughts?

On Fri, May 6, 2011 at 7:48 AM, Aaron Steele eightysteele@gmail.com wrote:

On it.

On May 6, 2011 2:21 AM, "andrewxhill" reply@reply.github.com wrote:

While you are in this area, there is a problem with Delete. If you load some layers. Then delete them. Then load more, the first set reappears.

Loading multiple point datasets at a time fails.

Reply to this email directly or view it on GitHub: https://github.com/andrewxhill/MOL/issues/44#comment_1110334

andrewxhill commented 13 years ago

Def, how quick do you need the mod?

eightysteele commented 13 years ago

Highly useful whenever ready. But I can stay busy in meantime.

On Fri, May 6, 2011 at 11:15 AM, andrewxhill reply@reply.github.com wrote:

Def, how quick do you need the mod?

Reply to this email directly or view it on GitHub: https://github.com/andrewxhill/MOL/issues/44#comment_1112772

eightysteele commented 13 years ago

Also, having a hard time reproducing the problems you found. When you get a minute, if you can tell me exactly how to reproduce (search inputs, exact steps, etc) that will rock.

On Fri, May 6, 2011 at 11:19 AM, Aaron Steele eightysteele@gmail.com wrote:

Highly useful whenever ready. But I can stay busy in meantime.

On Fri, May 6, 2011 at 11:15 AM, andrewxhill reply@reply.github.com wrote:

Def, how quick do you need the mod?

Reply to this email directly or view it on GitHub: https://github.com/andrewxhill/MOL/issues/44#comment_1112772

andrewxhill commented 13 years ago

Yeah, API call for multiple search names. Shouldn't the Points API act more like the Layers API and treat them as discrete units? Or are you thinking, if a user wants to get a layer of Puma points?

Okay, repro. Just tried to do the same thing a second time with no luck. I'll try again in a bit, working on getting our indexes nice and clean.

eightysteele commented 13 years ago

Yeah, API call for multiple search names. Shouldn't the Points API act more like the Layers API and treat them as discrete units? Or are you thinking, if a user wants to get a layer of Puma points?

So if a user select 5 points layers to add, right now, the client makes 5 different AJAX calls which is kind of inefficient and also requires keeping track of 5 async callbacks which makes state kind of messy. So, if the API supported multiple names, then the client could batch requests for the 5 layers into a single AJAX call with a single async callback. The resulting layers would still be discrete units though. Make sense?

Okay, repro. Just tried to do the same thing a second time with no luck. I'll try again in a bit, working on getting our indexes nice and clean.

NPAAD. I'll keep testing.

Reply to this email directly or view it on GitHub: https://github.com/andrewxhill/MOL/issues/44#comment_1112922

andrewxhill commented 13 years ago

Totally, but since the APIs to get layers should be standard, and now we can use a type:key_name query for all existing types, why don't I just rework the API to have a single entry point that takes an array of type:key_name pairs, and returns a result object of layers?

But that makes me start to see really big JSON objects being passed in single responses, bogging browser. So, 5 async calls or 1 big async call? Seems like the former is actually the better one, what is the issue at hand with state?

eightysteele commented 13 years ago

Hell yeah: http://r.fm/artist/la-fleur

Totally, but since the APIs to get layers should be standard, and now we can use a type:key_name query for all existing types, why don't I just rework the API to have a single entry point that takes an array of type:key_name pairs, and returns a result object of layers?

Heeeeeeeeeell yeah. Big +1 for key_name array input.

But that makes me start to see really big JSON objects being passed in single responses, bogging browser. So, 5 async calls or 1 big async call? Seems like the former is actually the better one, what is the issue at hand with state?

Wait. MOL needs to scale? Crap. Ok, how about we pass in paging params for each key_name and also set an upper bound on the number of key_names to process?

Reply to this email directly or view it on GitHub: https://github.com/andrewxhill/MOL/issues/44#comment_1112964

andrewxhill commented 13 years ago

Hell yeah: http://r.fm/artist/la-fleur

been on repeat all morning, they've been kinda off lately, finally..

Wait. MOL needs to scale? Crap. Ok, how about we pass in paging params for each key_name and also set an upper bound on the number of key_names to process?

y. paging def for long types. you will face the same issues of state i image? so. a user selects a point layer from a search result and says to add it. the client js takes off and starts asking the api for the data, the data gives back 5 points and says there are 100 more pages. how will that be handled in a very different way than now, i.e. single api calls per page?

eightysteele commented 13 years ago

y. paging def for long types. you will face the same issues of state i image? so. a user selects a point layer from a search result and says to add it. the client js takes off and starts asking the api for the data, the data gives back 5 points and says there are 100 more pages. how will that be handled in a very different way than now, i.e. single api calls per page?

right. ok. so the usecase i have in mind is when a user selects multiple point layers and then clicks the 'add' button. at that point, client can do 2 things.

1) send multiple ajax calls and store/process multiple async callbacks for initial load (multiple states to handle). problem is the browser can only have two tcp connections open at any one time, so it will be blocking.

2) batch multiple layer key_names into single ajax call and store/process a single async callback for initial load (single state to handle).

now, at this point, batching is kinda done. now a user looking at a single layer will say give me the next page for this key_name, and that fires a single api request.

maybe?

andrewxhill commented 13 years ago

right. ok. so the usecase i have in mind is when a user selects multiple point layers and then clicks the 'add' button. at that point, client can do 2 things.

1) send multiple ajax calls and store/process multiple async callbacks for initial load (multiple states to handle). problem is the browser can only have to tcp connections open at any one time, so shit will be blocking.

True, we should look into SPDY. Google already implements it everywhere else, so in GAE?

2) batch multiple layer key_names into single ajax call and store/process a single async callback for initial load (single state to handle).

now, at this point, batching is kinda done. now a user looking at a single layer will say give me the next page for this key_name, and that fires a single api request.

y. I think I agree with this at it's core, still have to think on it a smidddge. hah, yeah funny about git comment...

eightysteele commented 13 years ago

True, we should look into SPDY. Google already implements it everywhere else, so in GAE?

SPDY. Maaaaybe.

y. I think I agree with this at it's core, still have to think on it a smidddge. hah, yeah funny about git comment...

Yeah, fairly common pattern, and we could generalize so that our client RpcProxy (our mol.ajax module) sets a timer and batches all API requests from the app. Then, when the timer fires, a single batch request, with different API calls even, goes out. It's a pretty rad arch that def helps with latency stuff.

eightysteele commented 13 years ago

Fixed.