Transactional Service
For CERN this feature has a lower prio. For GSI the prio is high.
Collect requirements + discuss about a proposal (if there is one)
Possibility to choose if pending settings should be overwritten if setting happens twice before transactional-trigger
Event-ID is fixed per device (where to select) ? Or Event-ID comes with the settings?
"transactional = true" can be selected in the class per property ? Per field ?
flexible Multiplexing per BeamProcess
What is the plan / the features needed for this plan
variable multiplexing Depth
Currently fixed memory allocation ( main blocker: shm on split-process is allocated en block)
Possibility to use boost::interprocess instead of static shm-allocation
Opens the possibility to use std::types instead of plain C-Types ( std::vector instead of C-Array and std::string instead of char[123] )
CycleSelector string used for Get/Set/Subscribe
Currently at GSI:
FAIR.USER..
Desired by FESA:
FAIR.BP.
FAIR.SEQ.
Possibilities LSA ?
FESA-Inheritance - Dont use it any more for productive classes? Modify Guideline accordingly ?
?
This topic: FESA
>
WebHome
>
FESAMeetings
>
FESAWorkshopTopicsToDiscuss
Topic revision:
26 Nov 2014,
AlexanderSchwinn
Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki?
Send feedback