Plugin Interface improvements about dicoogle

[Enet4]

Ok, we do have some operations returning a Task<Report>, which may provide some fail-awareness. On the other hand, the interfaces should still explicitly state how errors are provided. I've seen IndexReport stating the number of errors occurred internally and logging them elsewhere, which would be fine if this class was known at the surface level. Programmatically, this subtype is hidden behind Report, which only exposes as much as an Object.

This lead me to a few more concerns: as stated by @tmgodinho yesterday, sometimes we don't want a program to wait for an indexation procedure or anything just as resource-intensive. This only means we have a need for both synchronous and asynchronous APIs. I've seen examples of SDK's providing both. How about we discuss and propose a new API that will be much more fitting for the future? :)

[bastiao]

As far I as remember, I also propose an sync API in the one Dicoogle Hackathon. The conclusion, and it was decided by all that we do not need, because we can synchronize the API anyway, waiting for the action.

[Enet4]

It sure is a debatable topic, but in that case the suggestion of making more operations asynchronous still stands. We should ponder about whether the current Task class is appropriate for retrieving a result, and redesign our asynchronous Report.

[Enet4]

Here are a few suggestions found in the headless branch:

• Revamp the current Report type into a hierarchy:
  • Each Report would aggregate multiple reports, potentially from sub-tasks.
  • QueryReport, extends Report and contains an iterable of search results.
  • ErrorReport, extends Report and contains an exception that would be thrown by a task.
• Replace query/index operations with query/indexClosure and query/dispatchDispatch. the Dispatch method would function similarly to what we currently have, creating and running a task asynchronously. The Closure function would enclose the operation in a task object without dispatching it immediately. The reason behind the existence of such closures is to support task aggregation into a super-task ran by a single executor entity.
• Remove queryAll operations in the plugin controller. Since query providers do not have a common query format, it is suggested that API users should always specify which providers to issue. Later on, we could have a separate set of methods with a unified query and result format.
• Have the executable application function as a CLI to a Dicoogle Server. Some of the suggested methods are -i (index), -i (index with all plugins) and -q (query).

[Enet4]

After tinkering with the unindex operation in the interface, I'm now feeling it's a bit too simple. It is unclear whether the operation is recursive (e.g. file:/foo would also remove file:/foo/bar), and no additional information on the success of the opertaion is provided but a boolean. Besides, what would one call a successful operation in this case? If the entry does not already exist, then we could either call it OK (since the outcome is the same anyway) or call it a problem (because the API user could be assuming that the entry really is there before removing the entry from the index).

[Enet4]

Discussion continues in #207.