aseemk / zoomit-js Goto Github PK

Zoom.it now has a batch API, which lets you send multiple URLs in one request. We should thus support that in our library.

A great way to do that would be to optimize multiple requests automatically "under the hood", so client code doesn't need to change. E.g. if Zoomit.getContentInfo() is called multiple times in the same event, the requests are delayed and are combined into one batch request immediately after that event.

It might be helpful to expose batch events (e.g. before/after batch request, or begin/end batch response), but we might want to worry about that only if apps end up needing it.

We currently only have an error event for Zoomit.getContentInfo(). It would be great to expose more specific info, like whether the error is a client or server one, or perhaps if the error is fatal or retryable.

At first I thought those might be the same, and they are in the case of getting content info (400 or 404 for bad URL or unknown ID; 503 for site down), but they're not in the case of requesting the DZI directly (via the new /v1/dzi endpoint; see issue 2) -- a 404 + Retry-After means processing and is retryable. Need to think about this...

While a functional style is nice, it might be useful to have and return an instance of some kind of Request object for API requests. This would have various benefits, like setting default options on the object's prototype or allowing requests to be canceled. This is also consistent with jQuery's style, e.g. $.ajax() is functional but returns a usable jqXHR object.

Zoom.it now supports webpage thumbnailing. We should thus add one or more wrappers to help with grabbing thumbnails from Zoom.it. For example, maybe a method to wrap a URL in zoomit://thumbnail/?url=, and/or maybe even a method to get the URL to a specific resolution (e.g. 256px) thumbnail directly (since thumbnail DZIs have a consistent and well-defined pyramid scheme).

Right now Zoomit.getContentInfo(url, callback) is not really much more than a JSONP helper. It does also abstract away the actual Zoom.it API endpoint URL and percent-encode the input, but that's about it.

Compare to the JavaScript quickstart which uses jQuery to make the JSONP request, and you can see that, at the end of the day, both techniques give you the burden of parsing the low-level JSON response object yourself. Even beyond that, there's boilerplate code to determine if the content is ready, failed or still processing.

It would thus be great if Zoomit.js could abstract away all these things and let you write just the logic you care to write. E.g. instead of just a single callback function that receives the response object directly, maybe have multiple callback functions for error, ready, failed and processing, and as options, all in the style of jQuery's $.ajax().

Zoom.it now has a /v1/dzi endpoint, which returns just the streamlined DZI object. We should thus add a Zoomit.getDziInfo() or similar, like Zoomit.getContentInfo().

A common use case is to keep retrying in-progress content until it's finished. We should support this, e.g. via a retry: true option, or maybe poll: true (in case we want to use retry as a callback for retryable errors; see issue 5).

Fix warnings, etc.

;)

JSONP requests fail silently, so we should have a watchdog timer to protect against those cases as well as a corresponding timeout event or so.