Re: Bug#689041: RFS: orthanc/0.2.1-3 [ITP] -- Lightweight, RESTful DICOM server for healthcare and medical research
[Filling in the blancs from Andreas email]
On Tue, Oct 9, 2012 at 11:04 AM, Sebastien Jodogne
<s.jodogne@chu.ulg.ac.be> wrote:
> 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.
I contacted ftpmaster and asked for a removal of the package then. Thanks.
> 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.
ok, that's great !
> (1) Should I create a Subversion tag for the upload by myself, or is this
> the responsibility of the uploader of the package?
See Andreas answer.
> (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)?
Yes. If you have a Arch: any package. The test will be run as part of
the rebuild on the specific arch. This is a fantastic tool to test
cross-platform exectution.
> b. Are they to be distributed along with the Orthanc binaries (e.g. under
> the name "/usr/share/orthanc/UnitTests")?
No. tests are build & run, but not installed.
> c. Are they to be simply ignored (as it is the case for now)?
You could potentially ignore a test on -say- ppc, until the bug is
fixed upstream...
> (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?
Can anyone backport something to oldstable from sid ? I do not believe
this is possible. I guess you need to talk to release team about this:
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> 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.
I do not understand the difference in between XML and JSON, but if
this make your process easier then it is fine with me. What I am
worried about is that DICOM is all about interoperability, while I do
not recall you ever posted your intentions on comp.protocols.dicom.
I have not looked at the implementation details, but how did you avoid
the whole BulkData handling of PS 3.19 with XML representation, simply
by using JSON instead. Does JSON supports arbitrary binary blobs ?
Thanks,
--
Mathieu
Reply to: