# Core team planning 27.07.2022 ## Service refactoring Common for every service 1. Rewrite via "task-wrapper" approach 2. Implement/remove extising "fixme" and "TODO" 3. Cover services with Doxygen(required) and diagrams(optinal) 4. Unit-tese coverage ### ContractCollectorService According to Carsten plans, should be implemented as minimal required amount of reatures for mode2. Can be refactored/implemented later. ### DartService General purpose of service - providing ability to read/modify (execute HiRPC) on dart. Also locates DART synchronize service. ### DARTSynchronizeService General purpose of service - synchornize dart with other instances. Struct Service State - what is REPLAYING_JOURNALS 1. Remove generate option and cases 2. Recorder replay func used only one time and is simple dart.modify request. 3. What is difference between DARTSynchronizeService::dartRead and DARTService::readDART (rename DARTSynchronizeService::dartRead) -> it is not only load data from dart, but also replying this data as responce. Change if statements to switch with default case - can be modified more easier. Common question - maybe we shpuld implement generic subscription mechanism. It can be used it all services and will be much easier to test. ### EpochDebugService According to Cartesn plans, should be ised during implementation new epoch updates. Can be refactored/implemented later. ### FileDiscoveringService General purpose of service is unclear. (used in mode1) Can collect data from adressbook and generate file? with general info Strongly need to be documented. ### LoggerService General purpose of service - be able to log enything from different part of program. Need to be refactored in BDD scope also. ### LogSubscriptionService General purpose of service - ability to customise received logs for every subscriber. Need to be implemented/refactored in BDD scope also. ### MdnsDiscoveryService General purpose of service - unclear (used in mode0) Logs are actually same as in FileDiscoveryService Strongly need to be documented. ### MonitorService General purpose of service - broadcast listener's socket. Who is listener, why not BroadcastService? ### NetworkRecordDiscoveryService General purpose of service is unclear Based on net-mode level able to collect data from each of them? Strongly need to be documented. ### Options It is not a service, should be removed to lib-base or something ### RecorderService General purpose - testing Contains to much function, structs. Must be spleated on several services/files. For now it is not even service. ### ServerFileDiscoveryService General purpose in unclear Must be used for mode2. Can be implemented/refactored later. Strongly need to be documented. ### TagionFactory General purpose - based on current net-mode spawn configured TagionService. For mode1 and mode2 just spawn TagionService with no additional configuration. Can be removed when we stop support mode0. ### TagionService General purpose - something like facade (not) which spawn all other services (mainly connected to network and dart) based on config. It can be hard to split/refactor. Not sure that simplifing is possible for this service. ### TransactioService General purpose of service - perform transaction operation. Not clear why it also contains "healthcheck" and "search" Need to be refactored (remove OLD). It is part of Carsten plan (same as for ContractCollectorService, can be refactored together) ### TranscriptionService General purpose of service - verifing receiving input and modifyDart??. Should not modifiDart(why? maybe it is better to redirect ot DARTService?)