Slicer3:UIDesign:WorkingProblems:SlicerInformatics:Draft1
Discussion at the NA-MIC 2009 AHM in Salt Lake City
Planning XNAT and Slicer integration next steps
Rough timeline for the next several months
Discussion points and action items
Deleting:
- resources (Use http delete),
- tags on resources, and
- tags from whole repository
Kevin will email wendy the API for the last two of these.
QA: detecting whether uploaded data is valid. WUSTL is thinking about QA; right now no provision. Future, maybe look at checksum on server side... Maybe there's a short-term soln: API provision for client to query for remote file size, and check this against local file size, the request file be deleted on remote host if no match...
Server ID: is there a way to validate a server as XND? We want to expose capability to 'add a new server', and a way to query the resulting servername for its identity, like
http://xnd.slicer.org:8000/identify
Kevin will look into this and update Wendy.
Security: no security yet. A first pass will come soon, probably http basic.
Tag/value length limits: There are no intentional limits on tag/value lengths. Long names and values may slow search time.
Special character restrictions: excaping all characters as for xml/html should be sufficient.
Note: WUSTL implemented a file browser metaphor for looking at hierarchy of resources, found that intuitive for users.
Note: XND current version is challenged by enormous datasets (like large collections of DICOM). Fix to this coming in version 0.8, with "collection support".
Note: Current XND version 0.7 is compatible with Slicer's existing implementation. Slicer will have to be modified to take advantage of Version 0.8's collection support: collections may not be supported by XND FileServer until a month or two after XND 0.8 is released. Misha will let Wendy know when draft API is available and advise.
Format tag: In the event that URIs don't contain an explicit extension (like those for XNAT-E, which also encode ticket info) we need some kind of tag on the dataset that Slicer can use to know how to open/load it. Current Slicer implementation automatically generates a "SlicerDataType" tag that it uses for that purpose. Better if we change that logic to use a "Format" tag that Slicer- and non-Slicer-people use. But we need to encourage the value assignments to be as consistent as possible. Can we create an XND default tag with a pre-populated set of values that takes a good stab at this? If so, Slicer can be modified to use "Format" instead of (or in addition to) "SlicerDataType".
Annotations, Thumbnails, and other derived data: We discussed the best way to accommodate annotations, and other data (thumbnails) associated with a particular dataset or collection of datasets. We would want to be able to:
- create these 'documents or datasets',
- upload them and associate them with a resource,
- query for them, and
- download them separately or bundled with data.
FetchMI release into nightly builds: This will happen soon after bug fixing and testing. Wendy will update XNAT team when module is released.
Cache Manager, Remote Data I/O ToDo List for Slicer 3.4 code freeze
- Fix Raise and rendering update behavior on CacheAndDataIOManager. When any data transfer takes place, it should raise, render itself, and then continue. After each data transfer, it should update.
- Disable Asynchronous IO option for now since that sometimes causes problems.
- Make sure "always redownload" is selected by default.
- Upload and download of MRML Scene files don't generate a DataTransfer entry -- not sure why. Only data files. Find and fix.
- Remove "Publish to XNAT" option from the File menu
- Make sure all path constructions are created with join, and not std::string "+"
FetchMI ToDo List for Slicer3.4 code freeze
- Logic & MRML
- trim off last ampersand in query
- make sure all query, delete, DL, UL commands exist in logic (so can be called from commandline)
- modularize architecture for multi-services (set appropriate handler in node)
- improve top-level positioning (now pops up in UL corner)
- efficiency: create a 'NewTagList' and add only new tags to DB instead of all tags at each upload.
- GUI
- add 'filename' column to ResourceList widget
- resort columns in ResourceList widget
- improve readability of current keyword/value pair in tagging panel
- put up a 'wait' message (or write text in status bar)
- implement show tags for individual dataset
- when a scene is closed, remove all tags from the empty scene's tag table.
- when a tag is deleted from datasets, raise the tagViewer with updated info
- Overall
- find and fix debug leaks: appears to be part of the TagTableCollection.
- want to be able to download any kind of Volume or Model or MRML file. Problem: inferring what kind of node to create from the uri of a remote resource. Currently, when a filename is passed in on the command line, loader.tcl parses out the filename and sends it to the AddDataWidget's logic; this figures out what kind of nodes to create for the data. When a filename is loaded through AddVolumes, AddModel, AddTransform, etc., the node is created directly. Probably need to build logic like the AddDataWidget's logic, that infers the node type from the filename -- if the uri contains a valid filename.
- test: save locally, then upload.
- test: download, local save, then upload.
- test: download, remove a dataset, then upload.