A just-in-time collection (JIT) is a collection that is dynamically generated for each view. Specifically, in JIT collections, the CXML and corresponding Deep Zoom image collection are generated by a web server at request time.
Compared to simple and linked collections, JIT collections can handle much larger and frequently updating data sources, but can be more complicated to implement and host.
| Simple | Linked | Just-in-time | |
|---|---|---|---|
| Source item count | <5000 | Unbounded, but complexity increases with size | Unbounded |
| Complexity of hosting | Simple; files on a web server | Moderate; many more files on a web server | Complex; server farm, database |
| Time to generate collection | Moderate; pre-compilation | Large; multiple pre-compilation steps | Minimal; generated at run-time |
| Benefits | Simple to create, deploy and host | Simple way to make hierarchical collections | Large data sources, real-time data, use enterprise access permissions |
The sample just-in-time collection server code available on this page shows an example of the request and response patterns that a server needs to handle in order to interact with PivotViewer. It also gives examples of the logic required to create the CXML and DZC XML responses, and how to place individual collection images onto a single image tile. It is not intended to be hosted “as-is," since, for simplicity and readability, it has omitted features typically expected of server software such as error handling, scalability and monitoring.
The sample just-in-time collection server code contains the following features:
Dynamically generated responses for CXML and DZC XML, and collection image tiles.
Ability to translate .jpeg and .png images into DZC and DZI (Deep Zoom Collections and Deep Zoom Images) at request time.
Ability to generate text-based visuals when images are not provided for an item.
Examples of creating collection views from the file system, SQL Server, OData, and Twitter.
When implementing a JIT server solution, it is especially important to keep scalability in mind. The sample code can be extended to suit a variety of needs and limitations. To improve the scalability of your solution, consider the following options:
Draw simple item content (perhaps just a single color) at low resolutions and the full detail for higher resolution requests.
Restrict the number of items returned in a collection view.
Cache the output returned by the server, the data from web service and database queries, as well as the source images.
Use a CXML supplement file for sending the description data that displays in the Info Pane.
Use asynchronous patterns for I/O, where appropriate, to avoid tying up the request thread pool on the web servers.
Pre-create DZI image pyramids and reference them from the dynamically generated DZC XML.
If you intend to run a PivotViewer web server farm, tune the configuration according to the needs and characteristics of your collection application. Some options to consider are:
Use a stateless approach which allows multiple requests from one client to be handled by any server in the farm, rather than relying on a 1:1 affinity between a client and one particular server.
Store all non-image data in a database while keeping the images elsewhere, e.g. a file store.
Distribute image tile generation across nodes, e.g. using a map-reduce style approach to parallelize the work appropriately.
Use a centralized or distributed server cache for the metadata needed to generate DZC, XML, image tiles, and potentially image data as well (beware of flooding your datacenter's internal network by transferring massive amounts of images between servers).
As with simple and linked collections, the PivotViewer allows you to quickly visualize the information within each collection view returned by a just-in time collection server. With this in mind, choose an appropriate number of facet categories and design your facet values so that applying them slices the view in ways that highlight interesting aspects and trends in the data. Select visual representations that are appropriate to the level of resolution displayed at any one time and which consistently support the message and insights your collection application is attempting to deliver.
With a just-in-time collection server, typically each collection view represents just a fraction of the items available in the larger backing data source. With this in mind, design your collection to include hyperlink facets that enable someone to launch a new collection view related to the current item in some way. For example, a collection view of household products containing an item for “table cloth” may provide multiple hyperlinks in the Info Pane that allow navigating to collection views associated with this item, e.g. “dining room”, “linen”, “matching items”, “blue”, “$10-$20”, or even provide actions such as “Add to cart” or “Send as email”.
Join our technical discussion to interact directly with the PivotViewer team. We hope you’ll join this community and share your work.
Comments (0)