Closed RFSH closed 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:
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.
@carlkesselman I agree with you that query parameter passing is not the right approach moving forward. So in my PR, I modified how chaise and osd viewer are communicating to utilize the message passing method. Although, I didn't remove the query parameter method as it can be used for debugging or using osd viewer without involving chaise. So what's described in this issue is still something that we should eventually address.
Ok, good. Keeping query parameter makes sense.
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 9, 2020, 10:45 AM -0800, Aref Shafaei notifications@github.com, wrote:
@carlkesselmanhttps://github.com/carlkesselman I agree with you that query parameter passing is not the right approach moving forward. So in my PR, I modified how chaise and osd viewer are communicating to utilize the message passing method. Although, I didn't remove the query parameter method as it can be used for debugging or using osd viewer without involving chaise. So what's described in this issue is still something that we should eventually address.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/informatics-isi-edu/openseadragon-viewer/issues/54#issuecomment-724202836, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AA3OGXWXTJDTLBB2N45KPALSPA2C5ANCNFSM4TLXDO7A.
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:.svg
, and then only check for.svg
..svg
.annotation_url
for annotations andurl
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.