thom17
commented
6 months ago 1차 시도 Call 을 추가했던 이유가 OMS의 업데이트였다. 따라서 이는 파일 별로 수행하는게 적절해 보이며 마찬가지로 OMS의 갱신 혹은 생성을 목적으로 두자.
- key= srcName
- value= {'node':Cursor,'call' : srcList} 이와 같이 자기 자신의 노드 그리고 관계를 srcName으로 (추후 연결할 수 있게)
먼가 계속 진행할수록 그냥OMS를 다시만드는게 나을것 같은..
초기 설계 및 고려 요소
이 프로젝트의 API 기본적인 Input 형태가 /request// 다.
request: stmt, line, call 이 있고 목적에 따라 키 값이 변경 되는게 핵심이다.
filePath: 실제로 파싱할 파일이며 이는 프로젝트에 속하여 clang이 정확히 파싱이 가능한것이 보장되어야 한다. (정확도 개선)
line_num: 가장 맘에 안드는 부분으로 파싱할 메서드의 위치이다.
초기에 메서드 하나를 타겟으로 필요시마다 호출하는 형태를 생각했다. (아예 파싱도 해당 메서드 부분만 하는 것을 고려했으니) 이유는 아래와 같다.
그러나 빈번한 호출 관계를 생각해보면 매번 파싱하는 것도, 요청하는 것도 비효율적인 것 같아서 메서드->파일 정도로 합의 보는게 맞는듯. FileInfo를 아예 갱신해보는것도 고려해볼만하다.
return json
json의 return의 키는 반드시 string 타입이다. stmt는 타입, line은 줄번호, call은 srcName이라 이것들은 아주 합리적이라고 본다. 결과는 stmt와 line은 List, srcName 은 Cursor이다.
현제 광범위한? 데이터를 제공 하는게 Cursor인데 이는 파일 기준으로는 합당한 걸까.. 이에 대한 고민은 필요하다.