앗, 저번에 웹앱스콘에서 뵈었던!! 어서 오세요~ 흐흐;

데이터 관리에서 데이터 교정 및 최적화 기능을 사용해보세요.
그래도 해결되지 않으면 서버 성능 문제이거나 너무 많은 태그 때문에 어쩔 수 없이 성능이 떨어지는 경우라고 봐야 할 것 같습니다. (사실 태그 기능이 텍스트큐브의 DB 관련 부분 중에서 가장 큰 부하를 주는 것이긴 합니다)

으음.. 그런 기능이 있으면(가능하면) 좋겠지만 웹과 HTTP의 하이퍼링크 특성상 단방향 링크이기 때문에 불가능합니다.
대안으로 사용할 수 있는 방법은 기존에 사용하던 도메인에 포워딩 처리를 하든지, 이중도메인 설정을 하는 것인데 후자는 현재 설치형 텍스트큐브에서는 지원하지 않고 있습니다. (블로그 방문은 가능하나 관리자 로그인 등에서 문제 발생할 수 있음)

..혹시 업그레이드하실 때 플러그인은 다 끄고 하셨는지요;
플러그인에서 문제가 발생하면 화면이 백지가 뜨는 수가 있습니다. (보통 이럴 때도 관리자 로그인은 직접 /owner로 접근하시면 가능합니다)

만약 이런 문제가 발생했을 경우 우선 관리자 모드에서 데이터 백업 등을 받아놓고 고치든지 다시 설치하시든지 하는 작업을 진행하시면 되리라 생각하는데... 이미 날리셨다니 안타깝네요..ㅠㅠ;

그 대충 짜도 돌아간다....는 건 IE에 딱 적용되는 말이군요. orz

문제는 그러한 특징이 그냥 어쩌다가 코드 건드리면서 취미 삼아, 혹은 그냥 자기가 원하는 어떤 목적 하나만 이루기 위해서 무조건 돌아가는 것만이 중요한 입장에서는 좋으나, 규모가 커지고 본격적으로 진지하게 다루는 입장에서는 오히려 마이너스가 된다는 점이죠.

사실 제가 요즘 빠져있는 python조차도 변수형이 정확하게 명시되는 언어가 아니라서 생기는 불편이 가끔 있을 정도니까요.; (다른 제반 환경이나 관습의 영향으로 그래도 비교적 깔끔한 편이긴 합니다. 물론 그렇다고 해서 모든 언어 java처럼 strict typing이 되어야 할 필요는 없겠지만요.)

...이런 식으로 계속 나가다보면 typing이라든지 functional이냐 아니냐 등등 프로그래밍 언어 수업이 될 듯...-_-;

네, 정말로 가장 강력한 장점이 있다면 맨 위에도 굵게 표시했듯 배포의 장점이 있을 겁니다. python이 제아무리 편하다고 해도 배포용 웹프로그램을 만들자면 대부분 설치 과정에서 관리자 권한을 요구하는 경우가 많이 발생해서 일반 웹호스팅에서 사용하기엔 아무래도 곤란하죠. (이쪽으로 맞게 구성된 전용 호스팅이 아닌 다음에야..)

또 perl이나 c와 비슷한 문법 체계를 도입해서 기존 개발자들이 보다 쉽게 웹개발을 시작할 수 있게 했고, 일단 찍으면 나오는 단순함으로 초보자들 역시 웹개발에 맛들이는 데 큰 도움을 준 것도 사실입니다.

제가 말씀드리고 싶은 것은, php도 그 자체의 목적을 보면 충분히 괜찮은 언어임에는 동의하지만, 텍스트큐브처럼 일정 규모 이상의 개발에 적용하기에는 조금 모자라는 부분들이 있다는 것이고, 여기에 덧붙여 제 개인적으로 그러한 불편함과 몇 가지 언어적 구조에 의한 직관적 코드 작성이 힘든 점으로 발생하는 스트레스를 잡담게시판에나마 풀어보고 싶었던 것입니다.

그나저나, TNF 개발자 분들이야 뭐 많이 다뤄보셨을 테니 불편하면 불편한 대로 편하면 편한대로 어쨌든 코드 작성을 하시겠습니다만, 취미 등으로 플러그인을 개발하시는 분들처럼 비교적 '덜 심각하게' php를 사용하시는 분들은 어떻게 생각하시는지도 궁금하네요.

사용카운트까지 갈 필요는 없고 존재 유무 체크하는 쿼리만 한 번 더 날리면 되겠지요;;

#1155 티켓으로 등록하였습니다.

결국... 모듈화가 덜 된 현재 상태에서 dispatcher로 바로 갈아타기는 무리라는 판단에 어제까지의 trunk를 흑역사(...)로 분기시키고 다시 엎었습니다. 제주도 호텔에서 밤새 삽질하고 서울 올라와서 오프미팅하면서 얻은 결론...이었죠.

지난 일주일 동안 깨달은 것은 inureyes님과 함께 2.0 프레임웍 구조 도입을 시도하면서 텍스트큐브 1.7까지의 기존 구조가 성능 면에서는 꽤 유리하다는 점이었습니다. interface에서 초기화 코드가 들어있는 파일들을 직접 부르도록 함으로써 중복코드도 생기고 코드 추적은 어려워진다는 단점이 있지만 덕분에 초기화 전에 각 interface에서 미리 체크해야 할 것들(input validation이나, 아이콘 핸들러인 경우 해당 처리만 하고 초기화하지 않고 끝내기 등)을 수행할 수 있었기 때문입니다.

우선은 현재 가장 큰 오버헤드가 큰 요소 중 하나인 includeFor*.php를 모두 autoload로 대체해야 하는데, 이렇게 해서 얻을 수 있는 성능 향상이 얼마나 될지는 아직 알 수 없습니다. 필요한 클래스만 불러온다 해도 URL 해석기를 쪼개든지 interface를 쪼개든지 해야 dispatcher에 전체 흐름 코드를 모아둔 상태로 성능 최적화가 가능한데, 쪼갠다는 것 자체가 php에서는 새로운 파일을 만드는 것과 같아져서 오버헤드가 증가하기 때문입니다. (지금까지는 require/include를 통해 'jump'해다니는 개념이었다면, 앞으로는 dispatcher만 보면 모든 실행 흐름을 한 눈에 볼 수 있도록 할 생각입니다) 게다가 이미 인터페이스 종류에 따라 불러와야 할 파일들을 따로 나누어 처리하고 있기 때문에 autoload에 의한 최적화를 하더라도 클래스 불러오는 시점만 달라질 뿐 결국 전체 불러오는 양에는 큰 차이가 없을 수도 있습니다.

하여간 이런저런 문제로 마구 갈아엎다보니 trunk가 좀 난장판(...)이 되었다는 게 결론;; orz

ps. 이런 고민을 막 하다보면, 과연 지금 생각하고 있는 2.0 추상화 구조가 php 언어에 적합하지 않은 것일지도 모르겠다는 생각마저 듭니다. namespace조차 없는 언어에서 하려니 어려움이 많군요. 확 python으로 갈아타고 싶습니다. ㅠ_ㅠ 2.0 성능 최적화를 위해 나온 아이디어를 중 상당수가 사실 django에서 이미 다 제공하는 거라는 거...

리눅스 쉘과 더불어 전설의 vi를 배워보실 때가 되었군요. =3=3

뭐, 요즘은 좀더 쉬운 버전으로 nano 같은 것도 있긴 합니다;