그렇다면 이 문제는 입출력만 처리해주면 끝나겠네요.
(글의 수에 비해 간단하게 마무리가 되어버린다는 느낌이; )

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

전자의 경우는 현재의 백업 구조에서도 아마 plugin 테이블 백업을 하고 있을 겁니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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