The .Net and Android modules are no longer maintained or supported. They should be removed from the code base.

Currently we can do new Equal(...).not(). We propose to add a less cumbersome format such as new NotEqual(...)

Now that nodes can process multiple jobs concurrently, it seems the next logical step is to allow these jobs to come from any number of JPPF drivers. In particular, this will address the problem of the driver being a single point of failure more efficiently.

This will impact manay areas of the code, including:
* processing within the node (of course)
* handling of connection/disconnection events in the node (node connection strategy, when should a node reconnect)
* should we allow the driver connections to be prioritized, as in the client, and permit a failover hierarchy of drivers?
* grid topology monitoring: the topology will no longer be a tree. In particular, the nodes will have multiple drivers as parents, which is a significanty change in the monitoring object model
* how iwll it affect load-balancing?

JPPF 6.2 introduced the concept of dependencies between Tasks and also between Jobs. It would be nice if this feature could be expanded with Tasks/Jobs having access to the result-value of the tasks/jobs it depends on.

Just a reminder to regenerate the reference doc for the configuration properties and update the offline and online docs.

We propose to implement a sample to demonstrate how to avoid JPPF drivers as single points of failure, with the following aspects:
* multiple drivers, not connected to each other (i.e. in pure failover mode). Each driver has a priority, the nodes connect only to the driver that is running with the highest priority
* a specific [https://www.jppf.org/doc/6.3/index.php?title=Defining_the_node_connection_strategy node connection strategy] for all the nodes, which allows the nodes to connect the driver that is up with highest priority
* a JPPF client as a controller, to detect when a driver with the highest priority goes back up, and force the nodes to reconnect to it

We propose to refactor the class representing the local executor in a JPPFClient, such that it implements the [https://www.jppf.org/javadoc/6.3/org/jppf/client/JPPFClientConnection.html JPPFClientConnection] interface. This will, in particular, allow a clearer semantics for the connection status events. Consequently, JPPFClientConnection should allow to distinguish between local and remote connections (with a isLocal() method for instance).

Whenever a JPPFClient attempts to connect to a driver, it will print out the status of the connection attempt to stdout. This can generate a lot of output whe'n there are many connections, and it may be desirable to disable the output. It will still be printed to the log.

Currently, a node will reconnect to a driver only if the driver connection is broken (e.g. when the driver is terminated or there are network problems) or when the node is restarted.

We propose to add a management function to force a node to disconnect, then reconnect, without having to restart.

Due to an error in the code, when registering multiple [https://www.jppf.org/doc/6.2/index.php?title=Managing_and_monitoring_the_nodes_through_the_driver#Registering_JMX_notification_listeners forwarding notification listeers], only the first one is properly registered, causing the others to not receive notifications from the nodes.

JPPF provides the ability to submit a job from a task already running in a node, but I realized we do not have any automated tests fro this feature