You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, Orchestrator generates the info.json request from a template, and then adds in additional information - like the sizes array, and auth services.
This approach is OK because the underlying IIPImage always generates the same info.json anyway - e.g. it always specifies 256x256 tiles.
This tile size is not necessarily the optimum, and other image servers might generate other tiles properties that depend on the particular properties of the image.
If we replace IIP with Cantaloupe, we should let Cantaloupe generate the info.json, and then decorate it with our additional info (like thumb sizes and auth services).
However, we can still optimise - we could store the image-server-generated info.json in S3 or the DB, either as-is or just the necessary data. While we can still use the request for an info.json as a trigger for orchestration*, we don't have to orchestrate to fulfil a request for an info.json - we can return our cached version while we orchestrate.
--
*With more and more optimisation to avoid orchestration, we need to think about whether an orchestration is triggered by an info.json request, or by analysing the actual image request to see if it really needs the orchestrated image. For example, if a client asks for the info.json and then makes a /full/full/ request, and we have #30, then we don't need to orchestrate. The trouble is we don't know whether that info.json request will be followed by a flood of tiles (in which case, orchestration-on-info.json is a valuable optimisation) or a request we can fulfill other ways (in which case, we wasted the orchestration).
Harvesting of info.jsons by an external crawler would also lead to unwanted orchestration.
The text was updated successfully, but these errors were encountered:
At the moment, Orchestrator generates the info.json request from a template, and then adds in additional information - like the
sizes
array, and auth services.This approach is OK because the underlying IIPImage always generates the same info.json anyway - e.g. it always specifies 256x256 tiles.
This tile size is not necessarily the optimum, and other image servers might generate other
tiles
properties that depend on the particular properties of the image.If we replace IIP with Cantaloupe, we should let Cantaloupe generate the info.json, and then decorate it with our additional info (like thumb sizes and auth services).
However, we can still optimise - we could store the image-server-generated info.json in S3 or the DB, either as-is or just the necessary data. While we can still use the request for an info.json as a trigger for orchestration*, we don't have to orchestrate to fulfil a request for an info.json - we can return our cached version while we orchestrate.
--
*With more and more optimisation to avoid orchestration, we need to think about whether an orchestration is triggered by an info.json request, or by analysing the actual image request to see if it really needs the orchestrated image. For example, if a client asks for the info.json and then makes a /full/full/ request, and we have #30, then we don't need to orchestrate. The trouble is we don't know whether that info.json request will be followed by a flood of tiles (in which case, orchestration-on-info.json is a valuable optimisation) or a request we can fulfill other ways (in which case, we wasted the orchestration).
Harvesting of info.jsons by an external crawler would also lead to unwanted orchestration.
The text was updated successfully, but these errors were encountered: