TObject for OTF archive and TF setting module

그동안 여러 시행착오를 반복하면서, VXFramework의 자료구조와 이를 기반으로 하는 각종 Interface가 안정화 되었지만 유독 찝찝함을 내제하고 있는 인터페이스가 바로 OTF  정의에 대한 것이었다.

사실 OTF를 정의하는 자료구조 자체는 큰 문제가 없었지만, 이를 설정하는 범위를 Native Frame에서 어느 범위까지로 하는가는 Managed Frame에서의 overhead와 직결되는 문제로 이해 했었다.

그러나 이는 "OTF 설정"의 범위를 광범위하게 정의하고, 작은 부분까지 Native 모듈에서 처리하게 하려는 욕심에서 비롯된 생각이었다. 그러나 OTF 설정을 다음과 같이 네 가지로 나누고

1. Control Point를 통한 Optical Color Array 지정
2. 지정된 Optical Color Array의 TObject Archive 할당
3. Optical Color Array의 Refinement (for adv. DVR)
4. 볼륨 분석을 통한 자동 Optical Color Array 지정

Managed 와 Native 모듈에서 맡아야 할 설정 범위를 생각해 보면, 이 모두를 Native 모듈에서 다 다뤄야 할 필요가 없음을 알 수 있다.
특히 Control Point 지정은 사용자 컨트롤과 자동 설정의 두 가지 방법을 통해 가능하며, 전자를 통한 지정 시 사용자 interaction 작업이 용이한 Managed Frame에서 작업하는 것이 더 효율적이라는 판단을 내릴 수 있다.

나머지 2,3,4번은 모두 Native TF Module에서 작업하되, 2번은 기능의 확장성을 고려하여 3번과 연계해 Default Manipulator 모듈에서 작업한다. 4번은 그 overhead를 고려하여 기존의 TObject를 정의하는 Archive 자료 구조 외에 CustomList object를 TF 모듈의 in/output 으로 이용한다.

위에서 설명한 부분 외에 Managed Frame 에서 TObject 조작을 위한 Component 설정을 편리하게 하기 위해, 내부에서 OTF 설정을 위한 VXFunctionScenario를 추가한다.

이를 통해 다음의 Managed Component 설정 코드가

이렇게 한 줄로 줄어든다. (설마 두 줄이라고 우기는 사람은 없겠지..)

-_-v 그러나 문제는........... 자료구조의 정리 및 Interface 변화로 OTF 모듈과 Managed Component 코드를 수정해야 하는 대작업을 해야 한다는 것! ㅠㅠ

이를 통해 다시 한 번 느끼는 것이지만 부적절한 자료 구조 및 interface 설계는 대재앙을 몰고 온다는 것..