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

• 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

• 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)
  • test delete resource
  • make pop-up confirm dialog when deleting resources
  • test delete tag from DB
  • make pop-up confirm dialog when deleting tag
  • improve top-level positioning (now pops up in UL corner)
  • disable ability to DL non-MRML datasets until implemented
  • 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.