Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
Dear Andreas and Mathieu,
I have just committed some modifications we have discussed yesterday.
By doing so, I have noticed that I forgot to submit a local copy of the
"mongoose-3.1.tar.gz" third-party dependency yesterday. This means that
the build of the package of yesterday will fail on the build machines,
since a HTTP download will try and download mongoose. This has been
fixed now, but the package should be re-sent. I am sorry for this
inconvenience.
Please also note that a new version of the upstream package (0.2.3)
should be ready in less than two weeks. It will incorporate all the
patches, will include more transparent support of Debian hardening and
will be able to use the "libgtest0-dev" system package to build unit
tests (as pointed out by Mathieu [2]). I think that working on improved
hardening and unit testing in the current 0.2.2 version would thus be
some waste of time.
I have some additional questions:
(1) Should I create a Subversion tag for the upload by myself, or is
this the responsibility of the uploader of the package?
(2) I am not sure to understand how I should cope with the unit tests:
a. Are they to be automatically run as a part of the build process (if
the CMAKE_CROSSCOMPILING flag is OFF)?
b. Are they to be distributed along with the Orthanc binaries (e.g.
under the name "/usr/share/orthanc/UnitTests")?
c. Are they to be simply ignored (as it is the case for now)?
(3) I would like to put my code on Subversion for backporting Orthanc to
squeeze:
a. Can I do it now, or should I wait for the sid package to be ready?
b. If I can work on this right now, how should I call this package
(orthanc-0.2.2-6~bpo60+1 apparently [1]), and in which directory should
I put the code in Subversion?
As a side note, where is the implementation coming from, is this JSON
binding describe anywhere in the DICOM standard ?
To the best of my knowledge, there is nothing in DICOM standard that is
stated about such a JSON binding, nor even about a RESTful interface to
DICOM stores. The closest match seems to be the WADO specification. In
the absence of such a specification, Orthanc implements a custom HTTP
API to close the gap.
Please also note that besides simple access to DICOM objects (WADO is
only for read access over HTTP), Orthanc will ultimately be able to
transfer DICOM objects to other modalities (C-Store SCU), to download
ZIP files containing series, to modify them (e.g. anonymization),... All
this by using a simple RESTful interface that is usable from most
programming languages (e.g. Python scripts).
We are working hard at the CHU of Liège on Orthanc, as it will greatly
ease our data management for clinical processes.
Cheers,
Sébastien-
[1] http://wiki.debian.org/BuildingFormalBackports#Modifying_the_package
[2] # cat /usr/share/doc/libgtest-dev/README.Debian
Reply to: