MUSIC 3.0 Proposals

[uahic]

I would like to propose to collect feature requests/improvement-proposals in this issue;

To start with some suggestions are:

Improvements:

• Moving the code base to C++11 and adding much more error checks; At some points the code just produces segmentation faults and its pretty easy as a user to cause them (e. g. try using the POSTPONE mechanism or passing a slightly inconsistent MUSIC config)

Feature request

Moving MUSIC to support service oriented architectures/interactive 'master/slave' use-cases such as the HBP-Neuro robotics platform and interactive visualization tools. Technically speaking this would include:

• ports that are not dependent on the ticking mechanism for sending messages
• remote-restart without destroying the MPI-context to restart all slaves with a given new config file/string and binary.

All of this implies a bunch of work and needs to be discussed of course

[mdjurfeldt]

Good idea to have a thread collecting feature requests!

We should change the title, though, becuase due to extensive changes of communication algorithms and scheduler, the upcoming MUSIC release will be 2.0.

I therefore suggest that we create an issue simply named "Feature requests".

For "improvements", we could start an issue with that title as well. However, everything which can be easily ticked off once it is done, like the move to C++11, could be an issue of its own.

Do you agree?

[mdjurfeldt]

However, that is stupid since that issue will grow partially old. I now realize that:

MUSIC 3.0 proposals

is better (along with what you already suggested).

[uahic]

Sure! And also interesting that there will be (or is already?) work on scheduling and communication algorithms