1

주제: 플러그인 구조 개선

간단한 이야기부터 :)

TTonWikipedia (얼마전에 공개했죠) 와 SoojungBinder (공개할 정도가 안되고 이건 계속 심심할때 건드리고 있습니다) 를 만들면서, 무지무지하게 '필요하다' 라고 느낀 것들이 몇가지 있습니다. 몇가지 hack을 통해서 그러한 기능들을 구현하려고 했었는데, 만들다가 그 한계에 부딪혔고, '그래 이게 무슨 삽질이냐' 라는 생각이 퍼뜩 들었습니다.

'무슨말이야?' 하시는 분들을 위해 실례로 제가 겪은 과정을 설명드릴게요 :) 공개가 되어있으니 TTonWikipedia의 예를 들어 보겠습니다.

본문의 내용에 계속 [wp]태그를 넣어주는 것이 귀찮고, 예전에 작성한 글들에 그러한 마크업을 하는 것도 힘들기 때문에 차라리 단어목록을 지정하면 그 단어들도 자동으로 위키백과로의 링크를 만드는 것이 어떨까 했습니다. 그러기 위해서는 사용자가 단어목록을 저장할 수 있어야 하지요.

그래서 index.xml에서 지정하면 제작자의 홈페이지 주소로 링크가 생긴다는 점에 착안하여 그 링크 주소를 플러그인 주소로 하고, 링크를 눌렀을 경우 환경설정 메뉴가 뜨도록 해 보았습니다. 거기까지는 일단 ok.

여기서, 플러그인의 환경설정이 가능하도록 지원해야 한다는 생각을 했습니다

그 다음에 단어목록을 저장해야 하는데, 일단 sql을 사용하기 위하여 새 글을 하나 만들고, 그 글을 데이터베이스로 사용하면 어떨까 하는 생각이 들었습니다. 그렇지만 그 경우 블로그에서 검색하면 단어목록의 단어들을 입력할 때 마다 검색이 됩니다. 그래서 포기. 파일입출력으로 가자! 해서 파일 입출력을 통하여 플러그인 디렉토리에 환경설정이 저장되도록 해야겠다는 생각을 했습니다.

그런데 거기까지는 좋았는데, 다중블로그의 경우 사용자마다 환경설정 파일이 달라야 할겁니다. 결국 저장되는 파일 이름에 사용자 아이디를 지정하거나 하는 식으로 여러개의 환경설정 파일을 만들어야 하는 문제가 생깁니다.

여기서, 파일 입출력을 통한 플러그인 환경설정은 정말 비효율적이라는 생각을 하게 되었습니다.

그리고, 이사를 가거나 할 때 백업기능을 이용하면, 그 전에 입력했던 단어목록들은 어떻게 되는거지? 라는 생각까지 하고서는 그런 식의 hack으로는 안되겠다, 그냥 플러그인 기능을 엎는게 낫겠다 했습니다.

결국, 각 플러그인의 환경설정값은 sql에 들어가야 한다는 결론이었습니다.

세 줄 요약입니다 :
* 플러그인의 환경설정이 가능하도록 지원해야 한다.
* 파일 입출력을 통한 플러그인 환경설정은 정말 비효율적이며 결국, 각 플러그인의 환경설정값은 sql에 들어가야 한다.
* 플러그인 아키텍처가 사용할 수 있는 필드를 유저별 sql 필드에 추가해야 하며, 그 값들은 백업시에 함께 저장되어야 한다.

이상이 의견이었습니다.
세 줄을 위해 잡설이 길었네요^^;

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

2

답글: 플러그인 구조 개선

저도 그런 생각을 했었습니다.

플러그인의 환경 설정과 그것을 저장할 수 있는 구조를 코어 컴포넌트를 제공해야 합니다.

여기에 덧붙여, 포스팅이나 댓글·트랙백 등 태터가 가지고 있는 DB 외에도 플러그인이 작동하기 위해 필요한 데이터 관리를 해주는 컴포넌트도 있어야 한다고 생각합니다. (아무래도, 업그레이드 등의 문제가 있기 때문에 기본 DB에는 손을 대지 않는 것이 좋겠지요.)

sql을 적당히 wrapping해서 API를 구성하면 좋을 것 같습니다.

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

3

답글: 플러그인 구조 개선

파파차님이 여기에 대한 댓글을 달듯 싶으시네요....  파파차님의 요새 화두가 스몰코어, 리치 콤포넌트인데 이게 그거에 해당하는지는 잘 모르겠구요..

일단 다음주 월요일 목표로 dev.tattertools.com 의 작업이 한참입니다.  개발과 관련한 이슈로 꽉 채워지는 사이트인데요.. wiki , trac , svn 등이 들어가 있더군요.  물론, 아무나 라이팅할 수 있는 권리는 안드릴 꺼구요... TNF 에서 열성적인 참여를 해주시는 분들 위주로 쓰실 수 있는 권리를 드릴 생각입니다.

개발트리 정리를 위해서 필요한 제반준비를 다 하는데도 시간이 오래 걸렸습니다.
그리고 지저분(?)하던 locale 관련을 깔끔하게 i18n 형식으로 바꾸었습니다. 이제 다국어판 제작하는데 많은 진전이 있을 것이라고 판단됩니다... 곧 오픈되는 개발트리가 나오면.... daybreaker 님.... 아시죠 ??

그리고 inureyes 님... 파파차님과 함께 역사에 길이남을 플러그인 인프라 부탁드립니다..^^

TNF 를 열성적으로 참여하시는 분들에게 Tatter&Company 의 과실을 함께 나눌 수 있는 프로그램을 운영하려고 합니다. 이제 저희를 사랑하시는 분들에게 고맙습니다...라는 말 이외에 실질적인(?) 과실공유 계획도 슬슬 모습을 드러내 볼까 합니다.. 그리고 이러한 것이 TNF 여러분들에게 좋은 선물이 되었으면 합니다. smile

4

답글: 플러그인 구조 개선

chester 작성:

파파차님이 여기에 대한 댓글을 달듯 싶으시네요....  파파차님의 요새 화두가 스몰코어, 리치 콤포넌트인데 이게 그거에 해당하는지는 잘 모르겠구요..

일단 다음주 월요일 목표로 dev.tattertools.com 의 작업이 한참입니다.  개발과 관련한 이슈로 꽉 채워지는 사이트인데요.. wiki , trac , svn 등이 들어가 있더군요.  물론, 아무나 라이팅할 수 있는 권리는 안드릴 꺼구요... TNF 에서 열성적인 참여를 해주시는 분들 위주로 쓰실 수 있는 권리를 드릴 생각입니다.

개발트리 정리를 위해서 필요한 제반준비를 다 하는데도 시간이 오래 걸렸습니다.
그리고 지저분(?)하던 locale 관련을 깔끔하게 i18n 형식으로 바꾸었습니다. 이제 다국어판 제작하는데 많은 진전이 있을 것이라고 판단됩니다... 곧 오픈되는 개발트리가 나오면.... daybreaker 님.... 아시죠 ??

그리고 inureyes 님... 파파차님과 함께 역사에 길이남을 플러그인 인프라 부탁드립니다..^^

TNF 를 열성적으로 참여하시는 분들에게 Tatter&Company 의 과실을 함께 나눌 수 있는 프로그램을 운영하려고 합니다. 이제 저희를 사랑하시는 분들에게 고맙습니다...라는 말 이외에 실질적인(?) 과실공유 계획도 슬슬 모습을 드러내 볼까 합니다.. 그리고 이러한 것이 TNF 여러분들에게 좋은 선물이 되었으면 합니다. smile

dev.tattertools.com 개장까지 한시간 반 남았습니다. 기다려 보겠습니다. lol
(아니면 25시간 30분 남은것일지도 모르겠네요)

질문 한 가지 있습니다. 저 위키는 개발에 관련된 이야기용으로 사용할 수 있는건가요?
예전에 TT홈페이지 소스 작업을 위키로 해보자는 이야기를 했었는데, 한 부분을 그런 목적으로 사용한다거나 할 수 있는지 알고 싶습니다. big_smile

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

5

답글: 플러그인 구조 개선

inureyes 작성:
chester 작성:

파파차님이 여기에 대한 댓글을 달듯 싶으시네요....  파파차님의 요새 화두가 스몰코어, 리치 콤포넌트인데 이게 그거에 해당하는지는 잘 모르겠구요..

일단 다음주 월요일 목표로 dev.tattertools.com 의 작업이 한참입니다.  개발과 관련한 이슈로 꽉 채워지는 사이트인데요.. wiki , trac , svn 등이 들어가 있더군요.  물론, 아무나 라이팅할 수 있는 권리는 안드릴 꺼구요... TNF 에서 열성적인 참여를 해주시는 분들 위주로 쓰실 수 있는 권리를 드릴 생각입니다.

개발트리 정리를 위해서 필요한 제반준비를 다 하는데도 시간이 오래 걸렸습니다.
그리고 지저분(?)하던 locale 관련을 깔끔하게 i18n 형식으로 바꾸었습니다. 이제 다국어판 제작하는데 많은 진전이 있을 것이라고 판단됩니다... 곧 오픈되는 개발트리가 나오면.... daybreaker 님.... 아시죠 ??

그리고 inureyes 님... 파파차님과 함께 역사에 길이남을 플러그인 인프라 부탁드립니다..^^

TNF 를 열성적으로 참여하시는 분들에게 Tatter&Company 의 과실을 함께 나눌 수 있는 프로그램을 운영하려고 합니다. 이제 저희를 사랑하시는 분들에게 고맙습니다...라는 말 이외에 실질적인(?) 과실공유 계획도 슬슬 모습을 드러내 볼까 합니다.. 그리고 이러한 것이 TNF 여러분들에게 좋은 선물이 되었으면 합니다. smile

dev.tattertools.com 개장까지 한시간 반 남았습니다. 기다려 보겠습니다. lol
(아니면 25시간 30분 남은것일지도 모르겠네요)

질문 한 가지 있습니다. 저 위키는 개발에 관련된 이야기용으로 사용할 수 있는건가요?
예전에 TT홈페이지 소스 작업을 위키로 해보자는 이야기를 했었는데, 한 부분을 그런 목적으로 사용한다거나 할 수 있는지 알고 싶습니다. big_smile

dev.tattertools.com 의 작업이 이제 끝을 보아가고 있는 것 같습니다...
dev.tattertoos.com 이 생기고 나면 .. 아마도 www.tatterstory.net 이라는 개발 블로그는 사라지게 될것 같습니다.
어제 밤에 머리아픈 오류가 하나 생겨서 오늘로 미루어졌는뎅.... 죄송하네용 ... ^^
그럼 최선을 다하고 있으니 조금만 기다려주삼요 ^^

6

답글: 플러그인 구조 개선

그러고보니, 여기에 등록되는 글들의 시간이 이상합니다.
분명히 없던 글이 새로 생겼는데 날짜가 4월 3일로 되어 있다든가..
시스템 자체의 시계 문제이거나 bbs의 설정 문제인 것 같군요.. (근데 그렇다고 해도 저렇게 일주일 이상 차이가 나면...-_-)

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

7

답글: 플러그인 구조 개선

daybreaker 작성:

그러고보니, 여기에 등록되는 글들의 시간이 이상합니다.
분명히 없던 글이 새로 생겼는데 날짜가 4월 3일로 되어 있다든가..
시스템 자체의 시계 문제이거나 bbs의 설정 문제인 것 같군요.. (근데 그렇다고 해도 저렇게 일주일 이상 차이가 나면...-_-)

아마 그건 이 글타래가 처음 생긴 날짜일겁니다. smile

댓글들을 보면 시간이 맞게 적혀 있지요.

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

8

답글: 플러그인 구조 개선

inureyes 작성:

아마 그건 이 글타래가 처음 생긴 날짜일겁니다. smile

댓글들을 보면 시간이 맞게 적혀 있지요.

엇, 댓글들도 이상한데요?;;

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

9

답글: 플러그인 구조 개선

daybreaker 작성:
inureyes 작성:

아마 그건 이 글타래가 처음 생긴 날짜일겁니다. smile

댓글들을 보면 시간이 맞게 적혀 있지요.

엇, 댓글들도 이상한데요?;;

흐음 제 화면에선 잘 보입니다.

개인 정보 설정에서 시간대가 맞게 설정되어 있는지 확인 부탁드려요 big_smile

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

10

답글: 플러그인 구조 개선

daybreaker 작성:
inureyes 작성:

아마 그건 이 글타래가 처음 생긴 날짜일겁니다. smile

댓글들을 보면 시간이 맞게 적혀 있지요.

엇, 댓글들도 이상한데요?;;

아하, daybreaker님과 inureyes님과의 엇갈린 부분을 찾았습니다.
저도 잠시 헷갈렸던 부분이구요..

daybreaker님이 잘못 표시된다고 생각하신 곳은 왼쪽 아이디 밑의 등록날짜를 말씀하시는 거겠구요.
inureyes님이 제대로 표시되고 있다 라고 말씀하신 곳은 댓글의 상단 테두리에 보면 댓글 등록날짜가 뜨는데,
그긴 정확한 시간으로 뜨고 있네요 ^^a

11

답글: 플러그인 구조 개선

음음 그렇군요;
이름 아래의 그 날짜는 사용자 등록날짜입니다. smile

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

12

답글: 플러그인 구조 개선

inureyes 작성:

음음 그렇군요;
이름 아래의 그 날짜는 사용자 등록날짜입니다. smile

포럼에 익숙하지 않은 제 불찰이로군요. orz

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

13

답글: 플러그인 구조 개선

inureyes 작성:

세 줄 요약입니다 :
* 플러그인의 환경설정이 가능하도록 지원해야 한다.
* 파일 입출력을 통한 플러그인 환경설정은 정말 비효율적이며 결국, 각 플러그인의 환경설정값은 sql에 들어가야 한다.
* 플러그인 아키텍처가 사용할 수 있는 필드를 유저별 sql 필드에 추가해야 하며, 그 값들은 백업시에 함께 저장되어야 한다.

저도 예전에 같은 생각을 했었습니다.
대신에 저는 sql이 아니라 개별 플러그인의 index.xml 파일에 추가가 되어야 한다고 생각합니다.
그렇게 된다면 태터 자체에서 어차피 index.xml 은 한번 읽기때문에 추가적인 부담도 줄일 수 있다고 생각하고요.
(배열로 받아두면 다중사용자일 경우 역시 문제 없겠죠? smile

방법은 대충 아래처럼 될거 같네요.

<plugin ~>
    ~
    <setup owner="1">
        <bgcolor>#000000</bgcolor>
        ~
    </setup>
    <setup owner="2">
        <bgcolor>#FFFFFF</bgcolor>
        ~
    </setup>
</plugin>

Peris (2006-04-12 18:41:08)에 의해 마지막으로 수정

14

답글: 플러그인 구조 개선

Peris 작성:

저도 예전에 같은 생각을 했었습니다.
대신에 저는 sql이 아니라 개별 플러그인의 index.xml 파일에 추가가 되어야 한다고 생각합니다.
...

저도 처음에 그 생각을 했었는데, 그 경우 백업기능 사용시 플러그인의 환경설정 백업 문제가 있더군요.
또한 파일입출력을 위해서 플러그인 디렉토리에 쓰기권한을 주는 것이 위험하기도 할 겁니다. smile

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

15

답글: 플러그인 구조 개선

inureyes 작성:

저도 처음에 그 생각을 했었는데, 그 경우 백업기능 사용시 플러그인의 환경설정 백업 문제가 있더군요.
또한 파일입출력을 위해서 플러그인 디렉토리에 쓰기권한을 주는 것이 위험하기도 할 겁니다. smile

제 생각에 백업같은 경우는 이렇게 하기로 결정만 난다면 별로 무리가 없을 거 같습니다.
(제가 다른 글에 적었듯이 플러그인까지 함께 백업 받아버리면 끝! 이니까요; )

파일입출력을 한다고 쓰신건 정확히 어느 시점을 말씀하시는건지 이해가 잘 안되서; 제가 이해한게 맞는지는 모르겠지만,
다른 글에 적혀있는 superuser 개념이 생긴다면 역시 큰 문제가 되진 않을거 같네요. smile

16

답글: 플러그인 구조 개선

플러그인 API에 사용자 설정 기능을 제공하는 것을 매우 필요하다고 생각되며, 첫 번째 티켓에 포함되어 있습니다. http://dev.tattertools.com/ticket/1
관련하여 구현이 필요한 것은 Property Editor입니다. 즉 Plugin Manifest (index.xml)등에서 사용자 설정 property description을 제공하면 이를 적절하게 form control 등으로 화면에 표시하고 저장하는 등의 기능을 수행하는 것입니다. 의견 주십시오.

PAPACHA (2006-04-14 14:51:08)에 의해 마지막으로 수정

17

답글: 플러그인 구조 개선

PAPACHA 작성:

플러그인 API에 사용자 설정 기능을 제공하는 것을 매우 필요하다고 생각되며, 첫 번째 티켓에 포함되어 있습니다. http://dev.tattertools.com/ticket/1

음.. 티켓을 좀더 잘게 나누는 것이 좋지 않을까요? 저는 첫번째 티켓이 Anti-Spam 관련한 것만을 말하는 것인줄 알고 있었습니다. 그리고 1.0.5 milestone에는 안 올라가 있더군요.

PAPACHA 작성:

관련하여 구현이 필요한 것은 Property Editor입니다. 즉 Plugin Manifest (index.xml)등에서 사용자 설정 property description을 제공하면 이를 적절하게 form control 등으로 화면에 표시하고 저장하는 등의 기능을 수행하는 것입니다. 의견 주십시오.

xforms처럼 세세한 컨트롤이 가능하지 않은(저도 써본 적이 없어서 얼마나 세세한지는 잘 모르겠지만..) 일반 html form을 사용한다면 제약이 많을 것 같습니다. 플러그인 제작자가 form을 만들 수 있도록 하는 것이 자유도 측면에서 더 나을 것 같다는 생각이 드는군요. (뭐, 그것마저 다 API나 xml 태그를 통해 체계화시킨다면―예를 들어 날짜 형식의 데이터를 저장하는 calendar라는 태그가 데이터 필드에 포함되어 있다면 그에 맞는 적절한 html form + javascript 덩어리를 출력해준다든가..―좋겠지만 코드가 길어지겠죠..-_-)

daybreaker (2006-04-14 15:19:55)에 의해 마지막으로 수정

문제의 답은 우리 안에 있다.
내면에 귀를 기울여 보자.

18

답글: 플러그인 구조 개선

첫번째 말씀에 동의하며, 그것에 대해 더 고민하기 위해 아직 새 티켓을 등록하지 않았습니다.
Property Editor를 제공하는 하는 이유는 GUI 작성의 편의성뿐만 아니라 저장 방법에 대한 통일성을 확보하는 API를 제공하기 위함입니다. 그렇게 되면 속성에 대한 정의만으로도 표현 방법과 저장 방법 등이 제공되기 때문에 버전업이나 migration, export/import 등에서도 그 설정을 계속 유지시킬 수 있습니다.

19

답글: 플러그인 구조 개선

DB에 대한 구현 부분의 제안입니다.

{prefix}PluginSettings 테이블
owner
pluginName
variableName[15]
variableValue[15]

variableName에는 변수명이 들어가게 되고, value에는 그 값이 들어가게 됩니다.
이 경우 variableName과 variableValue를 읽어들여 해당되는 변수명을 생성하고 복사하는 루틴이 추가되면 될 것 같습니다.

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

20

답글: 플러그인 구조 개선

inureyes 작성:

* 플러그인의 환경설정이 가능하도록 지원해야 한다.
* 파일 입출력을 통한 플러그인 환경설정은 정말 비효율적이며 결국, 각 플러그인의 환경설정값은 sql에 들어가야 한다.
* 플러그인 아키텍처가 사용할 수 있는 필드를 유저별 sql 필드에 추가해야 하며, 그 값들은 백업시에 함께 저장되어야 한다.

플러그인의 환경설정에 대한 방법은 'Property Editor'의 GUI 환경만 구현된다면 'index.xml'이나 'sql'를 통한 저장 방법은
크게 다를 것 없다고 봅니다. 서로 장단점은 있겠지만 이왕이면 'index.xml' 내에 처리하시는 것이 더 좋을 듯합니다.
Peris님 말씀처럼 플러그인의 환경설정은 플러그인내에 처리되는 것이 부담이 적을듯 하며, 백업이야 어차피 따로따로 받는것이잖아요
환경설정부분은 'Property Editor' 폼에서 모두 이뤄지는 것은 당연해야 될것 같구요. 전에 환경설정을 '.xml'을 이용해서 사진갤러리를
사용할수 있는 것을 써봤는데 폼에서 환경설정 하고 저장하고 등등 괜찮더라구요...
'Property Editor' 폼에서는 이미 정해져있는 옵션값을 보여주는 것은 기본이 되야하며, 추가적인 옵션값을 지정할수도 있으면 더 좋을 것 같습니다. 또한 태터의 스킨소스부분을 편집할수 있는것 처럼 'Property Editor'내에서도 플러그인 소스도 수정이 할수 있는 기능이 있으면 더 좋을것 같습니다.

당신의 삶속에 매화꽃 향기처럼 늘 아름다운 향기로 가득하길...
# J.Parker

21

답글: 플러그인 구조 개선

J. Parker 작성:

플러그인의 환경설정에 대한 방법은 'Property Editor'의 GUI 환경만 구현된다면 'index.xml'이나 'sql'를 통한 저장 방법은
크게 다를 것 없다고 봅니다. 서로 장단점은 있겠지만 이왕이면 'index.xml' 내에 처리하시는 것이 더 좋을 듯합니다.
Peris님 말씀처럼 플러그인의 환경설정은 플러그인내에 처리되는 것이 부담이 적을듯 하며, 백업이야 어차피 따로따로 받는것이잖아요

파일 입출력을 선택할 경우에 plugin 폴더에 쓰기권한을 줘야 한다는 문제가 있습니다 sad
그리고 다중사용자 모드의 경우, 예를 들어 만 명이 사용한다고 하면, 그 환경 설정을 파일에서 읽어오는 부분만도 로드가 장난이 아닐겁니다. (크기도 커지는데 그걸 그만큼 많은 사람이 계속 읽어오게 되죠) 그래서 sql 방식을 제안했습니다. smile multithread나 concurrancy등을 걱정할 필요가 없어지니까요.

"Everything looks different on the other side."

-Ian Malcomm, from Michael Crichton's 'The Jurassic Park'

22

답글: 플러그인 구조 개선

inureyes 작성:

파일 입출력을 선택할 경우에 plugin 폴더에 쓰기권한을 줘야 한다는 문제가 있습니다 sad
그리고 다중사용자 모드의 경우, 예를 들어 만 명이 사용한다고 하면, 그 환경 설정을 파일에서 읽어오는 부분만도 로드가 장난이 아닐겁니다. (크기도 커지는데 그걸 그만큼 많은 사람이 계속 읽어오게 되죠) 그래서 sql 방식을 제안했습니다. smile multithread나 concurrancy등을 걱정할 필요가 없어지니까요.

파일 입출력이 문제가 되겠지만 각각의 플러그인 환경설정 값들이 각기 다를 것이고, sql방식으로 했을경우 한 플러그인의 설정값의 필드 갯수를 정해놔야 하기에 설정값만큼 레코드값이 늘어 나야하는 것이~~ 그렇다고 플러그인의 설정값을 제한할수도 없는 노릇이고..
.xml방식이나 sql방식 장단점이 있네요.. ~~ 꼭 풀어야 할 숙제인 것은 명백합니다.~~ sad

당신의 삶속에 매화꽃 향기처럼 늘 아름다운 향기로 가득하길...
# J.Parker

23

답글: 플러그인 구조 개선

inureyes 작성:

파일 입출력을 선택할 경우에 plugin 폴더에 쓰기권한을 줘야 한다는 문제가 있습니다 sad
그리고 다중사용자 모드의 경우, 예를 들어 만 명이 사용한다고 하면, 그 환경 설정을 파일에서 읽어오는 부분만도 로드가 장난이 아닐겁니다. (크기도 커지는데 그걸 그만큼 많은 사람이 계속 읽어오게 되죠) 그래서 sql 방식을 제안했습니다. smile

sql이던 .xml이던 환경설정이 된다는 것이 중요한거겠죠. smile
(제가 말한거는 개념상으로 그쪽이 더 맞는거 같다는 의미였고요.)

만명이나 될 경우에는 .xml쪽이 더 퍼포먼스가 떨어지기야 하겠지만 sql도 그리 좋을거 같지는 않네요.;;

근데.. {prefix}Plugins 테이블이 이미 존재하네요.
owner int
name varchar255
settings text(현재는 다 NULL값)

settings에 적당히 구분자를 두어(variableName:variableValue|variableName:variableValue|~~ 같은..)
다 때려넣으면 현재 존재하는 테이블을 이용해서도 충분히 구현이 될거 같군요. smile

24

답글: 플러그인 구조 개선

일반적으로 settings (text) 안에 serialize한 값을 넣어서 해결하지 않나요?
owner=0 일때는 같은 종류의 플러그인에 적용되는 기본값 (모든 사용자에게 동일하게 적용되는 값),
owner>0 일때는 해당 사용자에게만 적용되는 설정값 (기본값과 다른 것만 저장)
이런 식으로 저장하고
owner=0인 값을 불러온 다음 owner=?인 값을 덮어쓰는(array_merge) 방식으로 하면 될 것 같네요.

25

답글: 플러그인 구조 개선

{prefix}Plugins 테이블 구조

owner      : {prefix}Users의 userid 값이 들어갑니다.    PK1
name       : 플러그인이름                               PK2
settings   : 플러그인에 필요한 값을 셋팅하라고 여분으로 남겨놓은듯..

settings에 필요한 값을  구분자를 넣어서 넣어주고 잘라먹으면
웬만한환경설정은 다 될것 같은데요.
테이블이 필요하면 만들어서넣어주면 되겠죠.

그리고 activatePlugin deactivatePlugin 이벤트도 지원해주셨음하네요
그때 필요한 작업이 있으면 만들어서 넣어주면 활용할수있는 범위가
늘어날것 같아요.

두가지는 어떻게 해결해야 될까요?
1. 백업시 플러그인에서 사용하는 테이블의 백업
2. 플러그인에서 사용하는 테이블의 완전삭제

제가 만들려고 하는 플러그인은 통계플러스로 블러그에 상세한 통계정보를 제공할려고 합니다.
테이블 설계도하고 어느정도 코딩도 해두었는데 1번과 2번 문제가 걸리네요..

webthink (2006-04-19 18:20:44)에 의해 마지막으로 수정