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)
    • make tcl procs into c++ logic (done)
    • move requestDL, UL into logic (done)
    • make parser base class and derive XNDParser HIDParser, move parsing methods there (done)
    • add a SelectedURIHandler to node.
  • efficiency: create a 'NewTagList' and add only new tags to DB instead of all tags at each upload.
  • escape all special characters in new tags & values before posting.
  • decode all escaped special characters in new tags
  • during a scene upload, keep track of all files uploaded so far. If something fails before MRML scene goes up, post message about what resource failed, then delete all component resources from the remote host (prevent partial upload footprint).
• GUI
  • improve readability of current keyword/value pair in tagging panel (done)
  • put up a 'wait' message (or write text in status bar)
    • figure out what's overriding the status text when server is selected & query is made (still hmmm)
  • 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
  • test: save locally, then upload.
  • test: download, local save, then upload.
  • test: download, remove a dataset, then upload.