Rigbox
Rigbox copied to clipboard
Allow multiple SCs, controlled by the same MC, to save to different remotes.
Related to the discussion in #190.
E.g. of the current situation, for MC, SC1, and SC2:
For MC:
p.mainRepository = '\remoteServer1\folder'
p.main2Repository = '\remoteServer2\folder'
For SC1:
p.mainRepository = '\remoteServer1\folder'
p.main2Repository = '\remoteServer2\folder'
For SC2:
p.mainRepository = '\remoteServer2\folder'
p.main2Repository = '\remoteServer1\folder'
In this situation, MC is unable to run an experiment on SC2, because they save to different main repos. Possible solution: At the time MC connects to SC, have MC query the SC for the SC's p.mainRepository
, and have MC save to that location.
Please don't devote any time to this. It will be a waste.
I can easily imagine a situation where a lab would want this. E.g., having different servers devoted to different experiment types, different types of subjects, different users, etc... It's not a pressing issue right now, but it's most definitely a useful feature, and something I don't want to forget about
I'd like to keep the issues list as a place for feature requests / bug fixes that users actually want. I regularly look through the issues as a way of seeing what needs doing. This is something that currently isn't needed by anyone. Each time the servers have changed in cortexlab we've set one of them to read only precisely to stop people writing to multiple locations. Other labs currently use mc to control only one stimulus computer. Now that this issue will appear in the suggested issues list can we close it until this is something an experimentalist requires?
I don't know how you're classifying "[things] that users actually want." There are a bunch of issues related to both enhancements and small bug fixes that you or I (or others, such as Nick and Kevin) have added that are ideas one person alone has come up with, i.e. without feedback from others. This would be a nice feature, and just because it's something that "currently isn't needed" (though if it had existed, it would've already saved me some time this week), I don't understand your urge to close it. I would like to have features/bug fixes that would be helpful, but aren't urgent, remain in 'Issues.' Tagging these types of issues with a label, such as 'enhancement' or 'priority:low' seems good to me. I think there are a bunch of other issues which share this issue's philosophy, such as #43 #55 #77 and more. Furthermore, a bunch of the todo
and fixme
comments in the code concern enhancements / ideas on future-proofing