implement access rights checks for operator code (e.g. DataSource), based on owner of operator instanciated
internal refactorings and improvements
performance improvements (large numpy arrays)
several bugfixes
operator architecture changes:
introduce input/output plugs, which allow to connect input/output streams dynamically. Ex: output of operator Map is "input stream + a geographic filter", thus this stream is completely virtual before the input is connected. So at first we just declare an input and an output plug, and when we plug the input stream, we can easily define the output stream at this time and attach it to the output plug.
renamed "stream" objects to "source" objects for clarity (the word "stream" should be reserved to the iteration of data records emitted by a "source").
Mike work update:
Operator for Steamer that will use sakura-gpu server -> working prototype, to be integrated to sakura system
Denis work update:
Tests on the deployed system, mainly entering new datasets, bug hunting
July demo outcome:
People were positive about it
We could know which missing features were most awaited for
New objectives:
Bug fixes, then notify Denis for more tests
GUI: Implement datastore grant request
Rework Sakura API (web) in order to allow user python code to use it, and use sakura platform without the web GUI (several people we saw at the demo would like this feature)
work on operators:
write new ones, general or specific (this was asked for at the demo too)
enable the "operators" tab on GUI
enable users to write new operators (make sure operator structure is getting stable, work on the definition of a "blank" operator, allow daemons to link to several source code repositories (users will write their operator outside sakura main repository))
generic operators should be able to move from one daemon to another (e.g. DataSource should run on the daemon linked to the datastore where the query is executed), transparently for the user