raphexion_'s comments

I was also thinking about Absinthe when I was read the release notes. Especially this line:

Compiler warnings and errors now include column numbers in addition to line numbers.

I remember reading this warning in the the Absinthe book (pg 90).

"Notice that the column value in the error is 0. Due to a current limitation of the lexer that Absinthe uses (flex)."

Do you think this will be solved as well?

Imagine that you have AI solution that do some calculations (e.g, stoke, bleeding in the brain). Often the calculations are very heavy and if you have a lot of data coming in you need to spread the load.

In dicom, a brain scan almost always span many, many dicom files. So when you push over one series, it can contain N images. Which means that there are N transactions to the server.

You cannot simply round-robin the load because all dicom files that belongs to the same series (study) must end up on the same worker.

So the goal of WolfPACS is to inspect the DICOM headers as they files come in, and route the files depending on the StudyUID and Calling AE.

So it is possible to associate certain workers with certain clients. So how a worker is picked is very flexible. Maybe you want to do some A/B testing. Or you want to take a worker offline "softly".

[1] https://github.com/wolfpacs/wolfpacs

Congratulation. Great work. It is such an ancient but important standard.

I just spent around one year writing Wolfpacs, a dicom load balancer in pure Erlang. (In my spare time).

Question: what is your take on the headers that are "undecided"? For example,the headers that have either signed short (ss) or unsigned short (us) value representation. Most of the parsing is "stateless" but a few headers require "rules". "If previous headers X is Y then VR=OW". I wished they could have made the standard better in that regard.