carlkesselman
commented
3 years ago I remain very concerned that the query parameter based approach is doomed to failure once we start including Z planes due to URL length limitations. Any modification to this should take into consideration that we may need to assemble several hundred (thousand?) files.
In IIIF, the way this is handled is via an explicit manifest file which is used to represent a related collection of images. While it may be overly complex for our use case, something that is consistent with this approach might be beneficial and provide flexibility for the future.
See: https://preview.iiif.io/api/content-state-0.3/api/presentation/3.0/
Carl
Dr. Carl Kesselman Dean’s Professor, Epstein Department of Industrial and Systems Engineering Fellow, Information Sciences Institute Viterbi School of Engineering Professor,
Preventive Medicine Keck School of Medicine
University of Southern California 4676 Admiralty Way, Suite 1001, Marina del Rey, CA 90292-6695 Phone: +1 (310) 448-9338 Email: carl@isi.edu Web: http://www.isi.edu/~carl On Nov 5, 2020, 10:34 AM -0800, Aref Shafaei notifications@github.com, wrote:
Currently, We're using url query parameter for passing both annotations and channel URLs. And then based on the value of the URL we categorize it as annotation or channel URL. The current logic looks for .svg or the predefined hatrac path (since the current annotations that are stored in hatrac don't include .svg.) This is very fragile and hacky and we should fix this. These are the solutions that we could think about:
- We could modify the asset annotation to include .svg, and then only check for .svg.
- Maybe we should do a hatrac disposition header request to figure out the filename and then use that for finding the .svg.
- Another solution would be using different query parameter names for annotations. We could use annotation_url for annotations and url for channel URLs. This would remove the need for checking the URL value in OSD viewer, but it would require chaise annotation changes in deployments.
That being said, we might want to use message passing instead of query parameters because of length limitations (like how I did it for annotations) and this might not be an issue anymore.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/informatics-isi-edu/openseadragon-viewer/issues/54, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3OGXW42S32XYQ6ARP75QDSOLV4HANCNFSM4TLXDO7A.
RFSH
Currently, We're using
urlquery parameter for passing both annotations and channel URLs. And then based on the value of the URL we categorize it as annotation or channel URL. The current logic looks for.svgor the predefined hatrac path (since the current annotations that are stored in hatrac don't include.svg.) This is very fragile and hacky and we should fix this. These are the solutions that we could think about:.svg, and then only check for.svg..svg.annotation_urlfor annotations andurlfor channel URLs. This would remove the need for checking the URL value in OSD viewer, but it would require chaise annotation changes in deployments.That being said, we might want to use message passing instead of query parameters because of length limitations (like how I did it for annotations) and this might not be an issue anymore.