Timeline for How to design a good generic tiled image downloader?
Current License: CC BY-SA 4.0
19 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 22, 2019 at 10:46 | history | edited | Doc Brown | CC BY-SA 4.0 |
Made some wording less specific to the languages involved
|
| Aug 22, 2019 at 7:18 | comment | added | lovasoa | The template-only dezoomer has to learn about the result of a request, but it doesn't necessarily have to launch the request itself. There are many advantages in it using the same core tile fetching component as the other dezoomers. | |
| Aug 21, 2019 at 22:08 | comment | added | Filip Milovanović | You can abstract the server (just come up with some really simple interface) for testing purposes. Also, regarding the stream approach: you don't necessarily have to notify such a dezoomer about special-case events (like "row end reached"), you just need to ask for the next tile, and the dezoomer should be able to figure out what to return next. It's worth investigating if there are other options, though (e.g., check if there's an API that lets you get the bounds then calculate all URLs based on that). | |
| Aug 21, 2019 at 22:07 | comment | added | Filip Milovanović | @lovasoa: Just my two cents (and it's fully possible that I misunderstood something of importance here) - if a dezoomer has to send a request & use the response in order to determine the next tile, there's no getting around that. So maybe dezoomers returning URLs is the wrong abstraction here - you could instead have them return some sort of a proxy or a promise that lets the core ask for the image itself (this action either downloads the image, or immediately returns the in-memory one - say if a dezoomer already downloaded it). | |
| Aug 21, 2019 at 20:06 | comment | added | Doc Brown | And concerning Rust: all you need to make this work are (lazy) iterators and higher order functions - Rust seems to have both. | |
| Aug 21, 2019 at 19:55 | comment | added | Doc Brown | I think these kind of details are best worked out in code - I gave you a starting point, now its up to you to make this work. | |
| Aug 21, 2019 at 19:55 | comment | added | lovasoa | (small note: I would like to implement this in dezoomify-rs, which is written in rust. Rust doesn't have a native event system, it would have to be implemented as well) | |
| Aug 21, 2019 at 19:50 | comment | added | lovasoa | Doc Brown: So, when a tile download fails, the core emits an event, stops consuming the current stream, and asks the dezoomer for another stream ? Isn't that redundant ? Maybe the method that provides the stream could be given the result of the last download directly. It would avoid having to implement an event system. | |
| Aug 21, 2019 at 19:46 | comment | added | Doc Brown | See my last edit. | |
| Aug 21, 2019 at 19:44 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 59 characters in body
|
| Aug 21, 2019 at 19:36 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 59 characters in body
|
| Aug 21, 2019 at 19:35 | comment | added | lovasoa | @Robert Harvey: I was simply saying that using streams doesn't solve the problem. Streams are a one-way communication method, and here, we need something that allows not only the dezoomer to stream URLs, but also the core to communicate with the dezoomer about when a download has failed. | |
| Aug 21, 2019 at 19:33 | comment | added | Doc Brown | @RobertHarvey: of course, my wording was not good. See my edit. | |
| Aug 21, 2019 at 19:33 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 59 characters in body
|
| Aug 21, 2019 at 19:30 | comment | added | Robert Harvey | @lovasoa: Don't expect to obtain an entire design from whole cloth here. That's your job. Our job is to point you in the direction that best suits your specific requirements. | |
| Aug 21, 2019 at 19:27 | comment | added | lovasoa | Thank you for the answer! This idea seems to be the way to go, but there are design questions that still need to be solved: what should be the interface between the dezoomer and the core? The dezoomer has to be able to provide a stream of tile URLs, but it has to be somehow notified of the point at which the stream was stopped in order to find MaxX... | |
| Aug 21, 2019 at 19:27 | comment | added | Robert Harvey |
one gets "testability" by making the download functionality replaceable by some "mock" download function. -- One gets "testability" by writing your tests first. Writing your tests first identifies the ideal API for your functions, not only identifying mockable parameters, but also minimizing the use of mocks.
|
|
| Aug 21, 2019 at 19:26 | history | edited | Robert Harvey | CC BY-SA 4.0 |
deleted 3 characters in body
|
| Aug 21, 2019 at 19:08 | history | answered | Doc Brown | CC BY-SA 4.0 |