Architecture

Some miscellaneous thoughts on the architecture

• Leverage other libraries where possible to minimize the amount of code to maintain and debug
• No web-app framework shall be utilized such as backbone, angular.js, ember, meteor or knockout.js. Cornerstone is focused on a layer lower than these frameworks and should not need them. Cornerstone should be useable with these frameworks though and possibly include adapters that make it easier to use in those frameworks.
• Prefer small simple libraries to bigger ones. (e.g. jQuery is too big)
• Do not use libraries that force dependencies on users of the library. For example, it should be possible for an app that uses a different version of a library than cornerstone to work properly
• It should be possible for an app and cornerstone to share the same library (as long as the version is supported by cornerstone)
• Asynchronous APIs should leverage the deferred pattern to return promises that callers can use to properly handle success and failure conditions. The excellent Cujo.js when library has great documentation about this (and will probably be used by cornerstone along with other cujo.js libraries such as rest and curl)
• The API should present a simplified view of the medical imaging domain to make it easier for developers to work with. For example, pixel data could be returned in modality units (e.g. hounsfield for CT) so the developer doesn't have to deal with applying rescale slope/intercept, masking pixel padding value, applying luts or dealing with overlays in the upper bits of the pixel. Color images would always be returned as RGB.
• Cornerstone should avoid pollution of the global name space through proper use of the javascript module pattern. Integration with other javascript module designs such as AMD and CommonJS should be possible but not required.