XNAT Discussion

General ideas

CTK XNAT Library

• Pull out the XNAT data structures from the plug-in and create a CTK library (there have been requests for that)
• Use virtual methods in ctkXnatObject subclasses for fetching the data (i.e. move the fetch methods from ctkXnatConnection to the subclasses) (It seems this exists already ? - Flo)
• Support asynchronous operations in ctkXnatObject?
• Support editing Xnat data and committing it back to the server (?)
• Think about user access rights and how to handle read-only access within setters of ctkXnatObject sub-classes
• Use ctkException as a base class for ctkXnatException
• Create (asynchronous) Qt models for displaying data in list, tree and table widgets
• Thinks about possibilities to generate GUI masks for editing or creating XNAT data objects
• Add a simple example application which reuses Xnat related Widgets from a (new) CTK library and allows to query a Xnat server
• Add querying support (https://wiki.xnat.org/display/XNAT16/Query+the+XNAT+Search+Engine+with+REST+API)

qRestAPI library

• emit resultReceived signal in the qRestAPI class (invalid)

Ideas from the London Hackfest

• ctkXnatServer: should it be an ctkXnatObject, or should we keep it at all. We keep it for now. Maybe adding for meaningful metadata about the server to justify the name, or maybe to rename it to ctkXnatRootObject or similar.
  • We went for ctkXnatSession as the class name
• Create a separate class for storing ctkXnatObject properties and share it between XNAT objects shared across projects. Make the ctkXnatConnection maintain a cache / map of ID->property object pairs.
• Possibility to set the parent in the xnat object constructor, as well by the setParent function.
• Check if the create/save functions could be unified to a single save function.
• Save all the properties of the xnat objects.
• Introduce a 'dirty' flag in ctkXnatObject that describes if the properties or the set of children has been modified. Not the children themselves. The save function should check this flag and not re-save the object again if it is not dirty.
• Introduce a modificationTime member in ctkXnatObject. The save function should update this. The reload function should check this property and retrieve the properties only if the 'remote' modification time is newer than our 'local'.
• Reload support. See previous point.

• Session support. Create a session when the user logs in. Use the returned session ID for the subsequent requests. If the session expires meanwhile, an exception should be thrown and processed in the client. The login dialog should be popped up or thing like that.

• Registering C++ classes to XML schema types.
• Download location. (already works)
• Zip/unzip support. Add QuaZip external project or copy MiniZip files to the XNAT library sources.

Ideas from the Heidelberg Hackfest

• Constants for common XNAT properties
• Modify the fetch methods to work on the cache and update the cache if necessary
• Cache
  • Check if ids for xnat objects are unique
  • Maybe introduce a ctkXnatObject::hash() method and operator==()