Are Scheduler and FileSystem passive on purpose

[blootsvoets]

Scheduler and FileSystem hardly do anything themselves, they need Jobs and Files to operate. Is this design on purpose? I would expect to submit a job to a Scheduler directly, or make a path on a FileSystem.

[blootsvoets]

@jmaassen indicated this design was to remedy the problem that in Java GAT it was unclear what actions were immediate, and what actions needed interaction with the underlying system. The philosophy is then that Scheduler and FileSystem do no actions (all their methods are in-memory) and that Jobs and Files do. A programmer then knows that whatever method it invokes on Scheduler, is going to be fast and have little (or no) side-effects.

This still runs counter to my intuition that a Scheduler DOES something, whereas Jobs sounds more like a passive and dynamic collection. Why not: SchedulerFactory.createScheduler (or even XenonFactory.createScheduler?), that creates a Scheduler that has actions and an in-memory SchedulerProperties?

This would be a large overhaul with little added functionality, so I understand this may be a passed station now.

[jspaaks]

I think it is reasonable to assume that programmers know certain actions are more expensive than others. For example, copying a big file to a harddrive on the other side of the world is going to be more expensive than instantiating a new object in local memory.

The question, however, is how to communicate this to the programmer, or in fact whether you need to do so at all.

My view is as follows:

1. the current way of communicating this does not serve the intended purpose; When I look at the passive/factory pattern I can't be expected to deduce that this is to communicate immediacy/performance of the operation--this is not what this pattern is typically used for (correct me if I'm wrong on this).
2. it is not strictly necessary to communicate this to the programmer through special code constructs (but you may opt to do so in the documentation, or in debug messages).

At the very least, we should add a line to the documentation of relevant classes stating whether there are any side-effects (like creating a file, doing something over a potentially slow network, etc.).

I'm not familiar enough with the Java world to know if it is feasible to expect people to do any profiling (It seems reasonable to expect people to first write an application, then test it, then profile it). Perhaps we could add functionality that would allow a programmer to check what's going on. I just had a similar discussion with @egpbos on slack, where I pointed to a visualization I made for esibayes: https://raw.githubusercontent.com/NLeSC/esibayes/master/src/mmsoda-toolbox/html/images/mmsodaAnalyzeTimings.png. I believe @Maartenvm has also made visualizations that help visualize what's going on (that was for JavaGAT if I recall).

[jmaassen]

Should add this to design decision document Issue #431