카테고리가 애매해보여서 이곳에 남깁니다. (난 개발자가 아닌데 자꾸 개발이야기에만 글을... ㅠㅠ)
지금은 개발이나 협업에 대한 불(의지)이 꺼져버려서 안하고 있지만 나름 XE를 빠르게 하기 위한 고심을 많이 했었지요. 이걸 계속 밀고 나갔으면 지금 어떤 모습이 되어있었을까요? @misol :)
XE는 여러 고절적인 문제 중 속도가 다른 CMS, 보드들과 비교되가면서 언제부터인가 기능 확장개선을 줄이고 성능개선을 고심하기 시작했죠. 그런데 제가 안타까웠던 점은 궁극적으로 자기들이 만든 소스를 개선해서 극적인 성능을 꾀하려는 노선이 아닌 외부 요소를 이용해서 (memcache 등) 하드웨어적으로 성능을 극복하려고 했던 점 입니다. 나는 분명히 여러곳에서 XE는 지금의 호환성을 버리지 않고 충분히 빨라질 수 있다고 생각하였고 깃허브에 이슈도 많이 남겼지만 번번히 거절되었지요. 지금에서야 그들이 보류라고 해놓은 것들을 보면 하기싫다는 메시지 였는지도 모릅니다.
nuricms의 향수를 느끼면서 예전에 꿈꾸었던 설계방안을 이곳에다가 뿌립니다. 그냥 이런생각을 갖고 있었구나하고 읽어주시면 되겠습니다. ^^
※Google 스프레드시트로 작성되었던거라 보기가 불편할 수 있으나 이해바랍니다.
| 개선안 | ||||||
| 들어가기전에 | ||||||
| 코어분리에 대해 제 생각을 정리해보겠습니다. 내용중에 추가할 점이나 다른점은 의견주시기 바랍니다. | ||||||
| 코어분리 | ||||||
| XE에서 코어를 분리한다란? | ||||||
| 현재 XE 구조는 개선을 거듭할수록 코어에 종속적인 모듈들로 인해 성능저하 및 호환성 문제 등이 발생되어왔습니다. 이 고질적인 문제점을 극복하고자 코어를 각 기능에서 분리합니다. 이로인해 성능의 향상, 서드파티들의 추가모듈과의 호환오류 최소화, 프레임웍으로써 개발툴로 사용 등 다양한 이점이 생기게 됩니다. | ||||||
| 아래 그림1과 같이 코어에 종속적이었던 모듈들을 코어안에서의 코드제거와 각 모듈로써 동작하도록 모듈을 개선합니다. | ||||||
| 그림1) | ||||||
|
||||||
| 단, 아래 그림2와 같은 유형의 모듈은 여러 모듈과 연결되어있는 복잡한 구조를 띄고있기 때문에 차후 코어를 개선, 보안해 나가면서 최종적으로 분리할 필요성이 있습니다. | ||||||
| 그림2) | ||||||
|
||||||
| 대상선정 | ||||||
| 아래는 의미적+기능적으로 코어에서 분리해야할 대상을 선정하기 위해 나열한 각 모듈과 기능들입니다. 분리가 필요한 대상은 O등 기호로 표기합니다. | ||||||
| 대상 | 분리필요 | 유지보수 | 이유 | |||
| modules | ||||||
| addon | ||||||
| admin | ||||||
| adminlogging | ○ | admin 모듈에 추가 가능 | ||||
| autoinstall | ○ | XE 공식용이라 지원필요없음 | ||||
| comment | ○ | document와 함께 분리 | ||||
| communication | ○ | member와 함께 분리 | ||||
| counter | ○ | 구글 통계나 다른 외부 툴로 대체 가능(삭제해도 될듯?) | ||||
| document | ▲ | 최종적으로 분리해야할 대상 상당히 복잡한 놈 | ||||
| editor | ○ | document와 함께 분리 | ||||
| file | ▲ | 다중 자원관리 등 추후 코어 또는 모듈로써 개선이 필요 | ||||
| importer | ○ | 분리 | ||||
| install | ||||||
| integration_search | ○ | 분리 | ||||
| layout | ||||||
| member | ▲ | 분리 | ||||
| menu | ○ | 분리 | ||||
| message | ○ | 분리 | ||||
| module | 모듈 모듈을 장기적으론 다른 형식으로 가져가는게 어떤가요? | |||||
| page | ▲ | widgetstyles와 함께 분리,개선? | ||||
| point | ○ | 분리 | ||||
| poll | ○ | 에디터 모듈의 종속 모듈, 분리? 개선? | ||||
| rss | ○ | 분리 | ||||
| session | ○ | x | 회원 모듈과 함께 분리(맘에 안들면 개선?) | |||
| spamfilter | ○ | document와 함께 분리 | ||||
| tag | ○ | document와 함께 분리 | ||||
| trackback | ○ | document와 함께 분리 | ||||
| trash | ○ | document와 함께 분리 | ||||
| widget | ||||||
| classes | ||||||
| cache | ▲ | 개선필요? | ||||
| context | ||||||
| db | 향후에는 mysql, mariadb 등으로 단일화? | |||||
| display | ||||||
| editor | ○ | 설정 정보를 $this에 올리기 위해 사용한건가요? 되도록 모듈안에 넣고 이곳에서는 삭제하는게 좋을듯 | ||||
| extravar | ○ | document와 함께 분리 (모듈로 만듬) | ||||
| file | ▲ | 다중 자원관리 등 추후 코어 또는 모듈로써 개선이 필요 | ||||
| frontendfile | ||||||
| handler | ||||||
| httprequest | ||||||
| ○ | 모듈로 만듬, libs에 있는 qmail을 모듈로 이동 | |||||
| mobile | ||||||
| module | 모듈 불러올 때 언어파일 같이 필요 없는 부분을 불러올 때가 있습니다. 필요 없으면 불러오지 않을 수도 있으면 좋겠는데 호환성이 난리 나려나요.. | |||||
| object | ||||||
| page | ||||||
| security | ▲ | 보안사항은 다양한 포멧을 서드파티가 추가할 수 있도록 모듈로 내림, 혹은 모듈과 연동시켜 다양하게 보안로직을 만듬 | ||||
| template | ▲ | 다양하게...(smarty, template_ 등) | ||||
| validator | ||||||
| widget | ||||||
| xml | ||||||
| addons | ||||||
| adminlogging | ○ | admin 모듈에 추가 가능 | ||||
| autolink | ○ | document와 함께 분리 | ||||
| blogapi | ○ | 분리 | ||||
| captcha | ○ | document와 함께 분리 | ||||
| counter | ○ | 제거? | ||||
| member_communication | ○ | member와 함께 분리 | ||||
| member_extra_info | ○ | member와 함께 분리 | ||||
| mobile | ○ | x | 분리?(WAP쓰나요?) | |||
| openid_delegation_id | ○ | x | 제거 | |||
| point_level_icon | ○ | 분리 | ||||
| resize_image | ○ | document와 함께 분리 | ||||
| widgets | ||||||
| content | ||||||
| counter_status | ○ | x | 제거 | |||
| language_select | ||||||
| login_info | ○ | member와 함께 분리 | ||||
| mcontent | ||||||
| widgetstyles | ||||||
| simple | ▲ | widgetstyles가 페이지 모듈안에서만 활용되는듯? page모듈의 향후에 따라 분리 | ||||
| 관리자페이지 설정(#1참조) | ||||||
| thumbnail | ○ | 모듈로 만듬, 기능 확장&개선 | ||||
| 하단(footer) 스크립트 | ○ | x | 레이아웃, 스킨 들에게 양도하고 해당 기능은 제거 | |||
| 기본 URL | 멀티 도메인이 수행할 수 있도록 다중 등록형태로 개선필요 | |||||
| SSL 사용 | ▲ | 잘 모르겠음(그대로 둘지 모듈로 뺄지..) | ||||
| 서버 포트 지정 | ▲ | 잘 모르겠음(그대로 둘지 모듈로 뺄지..) | ||||
| 짧은 주소 사용 | ▲ | 잘 모르겠음(그대로 둘지 모듈로 뺄지..) | ||||
| SSO 사용 | ○ | 모듈로 빼고 index에 올려둔 사항을 트리거 등 다른 내용으로 대체.. | ||||
| 인증 세션 DB 사용 | ○ | member 모듈안에서 호출 | ||||
| Qmail 호환 | ○ | mail 모듈안에서 호출 | ||||
| FTP 설정 | ○ | 쉬운설치가 없어지면 이 내용이 필요없어짐, 제거? | ||||
| 파일 업로드 | ○ | frontendfile? 모듈이었나요? 모듈로 이동... | ||||
| 파일박스 | ○ | frontendfile? 모듈이었나요? 모듈로 이동... | ||||
| 그외 | ||||||
| 사이트 제작/편집 | ○ | 제거 | ||||
| cafeXE(homepage) | ○ | site,vid의 가상도메인 개념이 카페XE 떄문인지라... 요것도 코어에서 분리할 대상으로 다루는게 좋을 것 같습니다. | ||||
| #1 관리자페이지 기본 설정 | ||||||
| 관리자페이지 상에서도 기본적으로 들어가있는 항목을 따로 모듈화시키는 작업이 필요할 것 같아서 제안합니다. 아래 그림3에 각 설정이 나타나있는데요. 저는 이 기능들을 따로 모듈화시키고 이곳 설정 항목에는 트리거를 달아놔서 호출하는 방식으로 분리를 했으면 합니다. 예를 들면 게시판의 추가설정과 같은 형태인거죠. | ||||||
| 그림3) | ||||||
|
||||||
더불어서 코어에 CSS 랑 Jquery 를 싹 제거하고 어드민 화면 페이지에 별도로 css 를 로드하도록 한다면 프론트엔드 개발이 더 잘 되었을 것 같기도 합니다.