bioinformatics-ua / dicoogle Goto Github PK

• Reports are not currently beeing return in the service response.
  ** Think they should be returned in a structured manner.
• Only a single plugin can be specified
  ** It makes more sense to be possible to select a set of plugins.
• Parameters are not complex at all, just plain strings.
  ** For the sake of coherence, they should be passed as simple parameters, therefore not encoded in json.

For different levels of the hierarchy, it should have a dynamic.

The tags.xml should be refactored to support it.

Example of response (from NEMA/DICOM).

https://gist.github.com/bastiao/dcf0744dd96e9708fcf6

It would be better to remove trailing character from the search webservice response.
Example:

• "StudyInstanceUID": "1.3.12.2.1107.5.6.1.123.24412.0.231616614823159\u0000\u0000\u0000\u0000\u0000",«
• "SeriesInstanceUID": "1.3.12.2.1107.5.6.1.123.24412.0.231737174002313\u0000\u0000\u0000\u0000\u0000",
• "SOPInstanceUID": "1.3.12.2.1107.5.6.1.123.24412.0.231019730551383\u0000\u0000\u0000\u0000\u0000"

Create a new slot for result web UI plugins in our web app, as well as at least one plugin to serve as an example.

The file header.jspf, which is included in all server pages of the web UI, seems to invoke startStatusRequestChain(true) on load, which is not defined. What is this supposed to do?

These options could be added to the Search service in order to make it more fexible.

• fields:
  • Select which fields will be returned in the query.
  • The default could be the DICOM DIM fields.

At the moment, restlet-based plugins are made by implementing a ServerResource and giving it a relative path. However, sometimes it would be more adequate to create a hierarchy of resources from that root, while still taking advantage of Restlet's URI templates. Using a router is the most trivial thing to do:

Router router = new Router(getContext());
router.attach("/items", ItemsResource.class);
router.attach("/items/{itemName}", ItemResource.class);

But right now we cannot attach this router restlet into Dicoogle. This could become critical when implementing services with the likes of WADO-RS, which would be nicely represented with templates (e.g /studies/{StUID}/series/{SeUID}/instances/{InUID}/frames). WADO-RS itself is part of the core, but other developers would prefer to have this.

Restlets are also much more powerful than simple Restlet server resources, allowing developers to create their own converters, for example.

Given that the GUI client is deprecated, we should also make sure that running the main executable without any arguments does not launch it by default. There are some alternatives:

• Start the server and open a web browser (if available) on the web application : -w
• Simply start the server : -s
• Terminate with an error and enforce the use of the current CLI arguments.

Which one should we choose?

I am a bit worried about how errors should be handled in Dicoogle's plugin interface. For instance, query(String query, Object ... parameters) in the QueryInterface has no throws specification, so there is simply no standardized means of reporting an issue during the execution. A few other methods throw IOException, but not all of them. Furthermore, some new exception types might make more sense here.

How have errors been handled so far? Don't you think we should update these interfaces?

Create slots in the webapp for injecting query web UI plugins, as well as one (or more) plugins as examples.

The main server instance (based on jetty, default port 8080) is currently hosting the web application and all built-in web services, but web services provided by plugins are still being served in another instance (restlet with simple server, default port 6060).

This issue aims to effectively address the matter in #22 and then have all web services in the same server (thus the same port).

A directory in the root maybe created with:

• licenses/server/
• licenses/client/

Then it could be like: react.js.txt and the license inside.

The web application's index page is loading some JavaScript libraries (and perhaps other web resources) from CDN's. We should keep all dependencies offline, preferably bundled.

Back in #11 it was explained why there shouldn't be a way to query all providers. How about we support configuring a default (or recommended) query provider instead? This holds the advantage that clients do not need to specify a provider for making simple searches, given that in many cases, only one provider is available anyway.

WARN servlet.ServletHandler (ServletHandler.java:513) - /dic2png
java.util.ConcurrentModificationException
at java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:966) ~[?:1.8.0_45]
at java.util.LinkedList$ListItr.next(LinkedList.java:888) ~[?:1.8.0_45]
at pt.ua.dicoogle.plugins.PluginController.getStoragePlugins(PluginController.java:272) ~[classes/:?]
at pt.ua.dicoogle.plugins.PluginController.getStorageForSchema(PluginController.java:319) ~[classes/:?]
at pt.ua.dicoogle.server.web.ImageServlet.doGet(ImageServlet.java:117) ~[classes/:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:735) ~[dicoogle-sdk-1.0-SNAPSHOT.jar:?]
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) ~[dicoogle-sdk-1.0-SNAPSHOT.jar:?]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:681) ~[dicoogle-sdk-1.0-SNAPSHOT.jar:?]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:452) [dicoogle-sdk-1.0-SNAPSHOT.jar:?]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:211) [dicoogle-sdk-1.0-SNAPSHOT.jar:?]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1083) [dicoogle-sdk-1.0-SNAPSHOT.jar:?]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:379) [dicoogle-sdk-1.0-SNAPSHOT.jar:?]

...

I do not believe that the enable method are called to start the Plugin (during the Dicoogle startup)

@tmgodinho it should be called right?

It was reported by one of our users (Milton Santos) that the web user interface fails exporting the results in some datasets. The user feedback was not completed, but it seems that that does not happens and the webservice that exports returns 500 error.

I believe that it is in the core due to the special characters or null values.

The current implementation of RunningIndexingTasks seems to work ok with our Lucene plugin. However, it reveals some flaws when applied to other plugins or simply more than one:

• When calling index(URI), each indexing provider is given a task of its own. However, these are not assigned a distinct UUID.
• It is currently not possible to know whether indexing tasks that do not give a task progress have finished. It is expected that their progress value is always -1. The servlet must provide a way to know when such tasks are finished.

With the deprecation of the Swing graphical plugin interface and the uprising of future use cases for Dicoogle, there comes a need for extendability at the web user interface level. Web Service plugins can provide web interfaces, but these are not integrated into the rest of the Dicoogle web application.

Here are some of the features that we are trying to cover:

• A user wants to perform a query by example (using content-based image retrieval). The best step into performing the query would be dragging and dropping an image into a file upload element in the Search page. The current querying interface is fixed to a basic querying method and an advanced querying method, which lack a means to send images. Future querying engines should be able to expose other query parameters in the interface itself.
• There may be cases where the querying engine(s) in use affect(s) what contents lie in a result. For instance, a CBIR query operation will provide results with a similarity property, and may not provide the remaining information about the results (such as patient name, patient/study/series ID). On the other hand, there are other interesting ways to show results that might not be covered in the web site, such as showing a grid instead of a list.

Below is a diagram with my proposal. The Dicoogle web page will provide specific UI slots for plugins to be inserted into (multiple plugins in the same slot could be separated with tabs). A Web UI plugin would compose a JavaScript module and a package descriptor (using a "package.json" typically seen in Node.js). An example of a package descriptor can be seen below. At the dicoogle subtree, it must contain at least the file name of the module and a pointer to the slot meant to be attached to.

{
  "name" : "cbir-query",
  "version" : "0.0.1",
  "description" : "CBIR Query-By-Example plugin",
  "dicoogle" : {
    "caption" : "Query by Example",
    "slot-id" : "query",
    "module-file" : "module.js"
  }
}

At the level of the actual module, a DicoogleWeb object would be exposed with some operations only relevant to the web interface. issueQuery would perform the query (thus passing all the data needed by the engine) and trigger a result plugin by invoking an event in the result slot. The onResult event function, implemented by each result web UI plugin, should take a list of results and expose them freely.

Let this issue be used to design and discuss Dicoogle's Web UI plugin interface. I will add more details as more suggestions and ideas come up.

When using the web interface, it appears to be impossible to save the "auto-start" configuration. When moving to another tab and returning to this one, the previous modifications to these checkboxes are gone.

The new servlet for forcing the indexing procedure is assuming that all index operations will return an IndexReport. This is currently not guaranteed by the SDK, and for now we must admit that a plain Report might be returned by the indexing plugin.

I have also seen the use of Java reflection to iterate through the report's getters and invoke them to obtain a complete list of entries from the report. Although I understand the concern of supporting a variable number of properties, using Java reflection here is not a good practise: it might retrieve information unrelated to the report (the plugin developer is currently oblivious to Dicoogle's core using reflection in such a manner), and may slightly cripple performance. Later on, version 3.0 will hopefully address this class hierarchy with a redesign of the SDK.

I suggest using a plain instanceof IndexReport for now to identify key cases where an IndexReport is obtained, and interpret a bare Report as "finished indexing".

By the way, as mentioned some time ago, the ForceIndexing servlet should not wait for completion.

The "Advanced" button in the search view behaves as expected, but it does not make clear to the user that clicking again reverts the search to a basic search. So I suggest that clicking this button should toggle between the captions "Advanced" and "Basic".

In small screens (mobile devices), the logos at the bottom may get in the way and prevent the user from filling the login form.

Correct typos and other incorrect words and sentences.

Make it so that the login credentials are submitted when pressing Enter.

Many of our servlets are currently accepting all origins, which is not safe. This should be carefully reconsidered, and we may start by removing all "Access-Control-Allow-Origin" header assignments in the servlets.

The typical output of the /dump web service (e.g. /dump?uid=1.2.840.113619.2.55.3.680960.718.1352967624.277.5&provider=lucene) would be:

{
  "results": {
    "uri":"file:/some/directory/to/dataset/IMAGE.dcm",
    "fields": {
      "SpecificCharacterSet":"ISO_IR 100\u0000",
      "InstanceNumber":"5.0",
      "StudyID":"1874",
      ...
    }
  },
  "numResults":1,
  "elapsedTime":"NA"
}

However, results becomes an array when the underlying query receives more than one result, which just might happen with multiple providers. /dump?uid=1.2.840.113619.2.55.3.680960.718.1352967624.277.5&provider=lucene&provider=cbir would yield:

{
  "results": [{
    "uri":"file:/some/directory/to/dataset/IMAGE.dcm",
    "fields": {
      "SpecificCharacterSet":"ISO_IR 100\u0000",
      "InstanceNumber":"5.0",
      "StudyID":"1874",
      ...
    }
  },{
    "uri":"file:/a/b/c/img.dcm",
    "fields":{...}
  }],
  "numResults":1,
  "elapsedTime":"NA"
}

This leads to unexpected behaviors in consumer applications. The web application itself is not prepared for this either.

@fredericojssilva is it already implemented?

The Remote Swing GUI interface is currently deprecated, and we wish to remove it eventually. Unfortunately, as a result of bad design, some vital features of Dicoogle are unnecessarily coupled with rGUI contents (e.g. server.web.auth.Authentication depends on User-related classes with RMI characteristics).

We should decouple these features from the remote GUI so that it can be safely removed.

We used to write all log entries in Dicoogle to "DICOMLOG.log", but this is no longer true if the logger system is configured to writer to another file (such as what we have right now in "dev"). If the file does not exist, the server will currently fail to process logger requests in this servlet.

To fix this, we can do one of the following (suggestions are welcome):

• Check all log4j2 appenders in runtime and read the file of the first occurrence of a file appender;
• Programmatically add an appender (which will always exist regardless of the config file) and use it to retrieve the logs.
• Enforce all log writing to a specific file, such as "./DICOM.log". I'd preferably avoid this.

I really think this issue should be fixed in 2.0. Poking @fredericojssilva in case he's still working on this.

My idea is to extend our SDK to allow to easily do C-MOVE to external servers and DICOM queries.

@tmgodinho what do you think? It will allow to do easy communication with external PACS

In order to create a flexibility of integrate the interface with third-party modules, I'm suggesting to support three end-points with direct access to the UI (something like that) :

• ui/search?query=
• ui/image?SOPInstanceUID=
• ui/dump?SOPInstanceUID=

By default, including all node_modules dependencies is quite heavy and time spending.

We seem to have an implementation of thumbnail generation in the core of Dicoogle, but it is not integrated to indexation/searching procedures. We cannot have thumbnails in our web application unless:

• indexed images are issued and indexed for thumbnail generation
• these thumbnails are retrieved when listing a query result.

The project is currently relying on multiple logging frameworks, each class appearing to have an independent choice: either java.util.logging or Apache log4j. In addition, slf4j was actually included as a dependency, but barely used in our code.

My suggestion is to adopt slf4j to the entire project and future code, thus being completely abstracted from the underlying logging framework. There is a tool for migrating our current code. I am currently experimenting with it in a separate branch. Meanwhile, I would like to hear your opinions.

Ever since we moved to Jetty to host our services, we went back from Restlet to servlet programming, which you know is significantly more frustrating and time consuming.

There is an extension for adding Jetty 9 support to Restlet. I know we do have a bunch of servlets implemented already, but if we can manage to support both servlets and restlet resources under Jetty, what do you say about relying on Restlet again for future WS development?

Whenever an attribute value is too large to fit in the table's fixed width, this happens:

The web page seems to be rendering many redundant React <span> elements when the list of image results is shown.

How to reproduce:

1. Perform a search with some results;
2. Select a patient, a study, then a series;
3. Invisible <div> elements (from the virtual <span>s) are rendered to the page.

The number of running tasks should not count those already finished.

Dicoogle has currently two dependencies (net.sf.json and com.google.gson) that can do the same thing: encode and decode JSON. I may also point out that Gson is nicer to use than the other one. What do you think about sticking to just one dependency?

Should be able to support HTML5, JS, CSS files etc. Will be nice to embed the Extensions inside the plugin.

Expose the un-index feature through the web service. It was available in version 0.5 and now it is not available anymore. It needs to be re-implemented.

Requested by Smirnov Denis.