3,501 inureyes이 작성한 답글

(23 답글들, 잡담하기에 작성)

음 독립된 저장공간에 올린 후 링크라면 정말 중복되는 문제가 있겠네요. ;

일단은 중복되면 각각 첨부 식으로 해야 하지 않을까 합니다. 나중의 버전에서 바뀌더라도, 현재의 버전은 그렇게 되어 있으니까요. smile

포럼으로 이동: 잡담하기

3,502 inureyes이 작성한 답글

(3 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

넵 체크루틴 집어넣어서 없애도록 하겠습니다 >_<

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

3,503 inureyes이 작성한 답글

(3 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

그거 언젠가 여기서 논의해서 슬래시 지원 빼자는 결론이 나왔습니다.
그게  body id 지원에 관련된 초창기 논의 때 였던 것 같은데 잘 검색이 안되네요 ㅠ_ㅠ 다시 한 번 검색해 보겠습니다 smile

(이제 검색해서 쉽게 찾기에도 글이 많군요 yikes  )

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

3,504 inureyes이 작성한 답글

(14 답글들, 아이디어 및 기능 제안에 작성)

대충 검색하다 마지막 해결글만 찾았네요 smile

http://forum.tattertools.com/ko/viewtopic.php?id=209

포럼으로 이동: 아이디어 및 기능 제안

3,505 inureyes이 작성한 답글

(5 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

지금도 안되나요? 재현이 안됩니다. ㅠ_ㅠ

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

3,506 inureyes이 작성한 답글

(10 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

chiri님 관리자 메뉴에서 디비 최적화하기를 선택해서 실행해 보아 주세요 smile

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

3,507 inureyes이 작성한 답글

(5 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

확인했습니다.

관련하여 blogURL, defaultURL을 제대로 파싱하도록 수정하였습니다.

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

3,508 inureyes이 작성한 답글

(3 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

(아마) 고쳤을겁니다.

이메일 필드 파싱하도록 해 놨는데 그게 넘어오는 값까지 건드렸는지는 잘 기억이...

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

3,509 inureyes이 작성한 답글

(23 답글들, 잡담하기에 작성)

lacovnk 작성:

첨부파일 빼놓고 잘 동작하는 것 같습니다. 첨부파일은 정말 어쩌지 -o-

제일 속편한 방법은 디비대 디비로 옮기지 않고 백업 복원용 xml을 만드는 것입니다 ㅎㅎ
원래 파일명으로 만들어서 넣으면 복원시에 알아서 척척척 -

포럼으로 이동: 잡담하기

3,510 inureyes이 작성한 답글

(9 답글들, 아이디어 및 기능 제안에 작성)

일단 저장은 지금처럼 따로 하는 것이 좋을 것 같습니다. 관리자 화면에서 트랙백을 따로 관리하고 정리하는 기능이 있고, 댓글의 경우 태터툴즈끼리는 쓴 댓글과 답글을 xml ping을 통하여 추적할 수 있는 댓글 알리미 기능이 들어있기 때문에 통합하면 양쪽의 장점을 희석시키게 되죠.

그리고 트랙백에 핑백 부분도 추가될 것을 고려하면, 현행처럼 저장은 따로 하는 것이 확장성을 위해서 좋을 것 같습니다. smile

포럼으로 이동: 아이디어 및 기능 제안

3,511 inureyes이 작성한 답글

(2 답글들, 잡담하기에 작성)

후딱 내려! 라는 말로 이해하겠습니다 ㅠ_ㅠ 죄송;

포럼으로 이동: 잡담하기

3,512 inureyes이 작성한 답글

(16 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

네 그냥 수정 못하게 하죠 ㅠ_ㅠ

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

3,513 inureyes이 작성한 답글

(16 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

수정 가능 했는데... 흑 ㅠ_ㅠ

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

3,514 inureyes이 작성한 답글

(14 답글들, 아이디어 및 기능 제안에 작성)

lacovnk 작성:
daybreaker 작성:

1번의 경우는 원파일명으로 따로 거르기 위해선 별도의 php 파일을 두고 mod_rewrite를 이용해 url을 파싱 후 DB에 접근하는 삽질이 필요할 것 같습니다. 파일 시스템에 올라가는 건 원래 파일명이 아니니까요..; (일단 현재처럼 고유id를 생성해서 숫자로 붙이는 경우에 말입니다)

언어에 독립적인 것이란 뜻은, 한글 서버에서도 잘 돌아가고, 아랍어 서버에서도 잘 돌아가고, 중국어 서버에서도 잘 돌아가고... 뭐 이런 걸 말하는 거겠지요. 모든 서버가 다 유니코드를 쓰고 모든 웹브라우저가 다 유니코드로 url을 보내준다면 참 편하겠지만 실제론 그렇지 않으니까요. 아직까지 한글이 아닌 다른 비영어권 언어를 쓰는 환경에서 어떻게 돌아가는지는 잘 모르겠습니다;

그리고 php 요구사항은 아마 php4.2 이상인가? 그랬던 걸로 기억합니다만, 정확한 건 교주님이...=3

앗 daybreaker 반가워요 smile 여기서 보는군요..

1. 어차피 다운로드 할 때 원래 파일명을 보존하기 위해서 php를 거치며 db를 찾아보니.. 피장파장이긴 합니다 ㅎㅎ

2. urlencode로 인코딩 된 것을 잘 사용하고 있는 dokuwiki가 있습니다.
중국어 링크도 잘 됩니다. http://www.allwiki.com/wiki/%E7%94%B5%E … D%E5%85%B8 처럼..

한글 서버, 중국어 서버.. 라는 것이 어떤 의미인가요? lang 변수에 ko_KR이 있으면 한글 서버일까요? sad urlencode를 지원하고, 인코딩을 하나로 결정해서 내부에서 쓰면 별 문제가 되지 않는 것으로 압니다. (mysql에 latin1이라고 해놓고 utf8를 넣어버려도..) 그리고 urlencode된 결과는 "화일명"으로 처리할 수 있습니다. 그리고 urlencode된 결과를 사용하면 "어떤 인코딩으로 한글을 주소로 사용할 것이냐"에 해당하는 해묵은 문제는 해결됩니다 (UTF-8 옵션..덜덜)

서버 환경이 문제가 되는 것은 예전에 iconv가 php에 포함이 되어 있지 않아서 이전 euckr으로 사용하던 태터를 utf8로 업그레이드할 때 발생한 경우였던 걸로 기억합니다.

아, 그리고 추가 질문 들어갑니다..

1. 서버 특성 때문에 어려움을 겪은 내용을 정리한 문서가 혹시 있나요?
2. 현재 태터에서 요구하는 설치 조건으로 아파치와 php, mysql을 요구하는데 그 것만으로도 언어에 상관없이 구현할 수 있는 것으로 압니다. 혹시 설치 조건을 완화하는 것을 목표로 하고 있나요?

1. server side iconv가 없어도 태터는 돌아갑니다. smile (속도 문제가 있지만 적어도 돌아갈 수 있는 대비는 되어 있습니다)
2. 인코딩에 대하여 부연 설명을 드리자면, 여기서 한 번 검색해 보시면 이와 유사한 '인코딩' 문제에 대한 격론을 찾아보실 수 있습니다. '사람이 읽을 수 있는' 부분과 '기계가 읽을 수 있는' 부분에 대한 논쟁입니다.
3. UTF 기반이 아닌 디비에 UTF를 구겨넣는 것은 단순히 urlencode등으로 되는 문제는 아닙니다. 넣고 빼는 것에는 문제가 크게 발생하지 않지만, 그건 저희 목표와는 거리가 멀거든요 smile 지원하지 않는 서버에서 '완전히' UTF8을 에뮬레이트 하는 일은 소팅이나 의미론적 문제를 포함하여 사실 굉장히 어렵습니다.
4. WP나 MT에 비하면 CJK권 지원은 매우 나은 편이지만 (이 프로그램들은 디비에 구겨넣고 꺼내는 것 이상은 신경을 써 주질 않습니다), 서버 특성에 따른 내용의 리포트는 끝이 없을 정도로 많이 있습니다 (정리하기 힘들 정도로ㅠ_ㅠ)... 태터툴즈 메인 페이지에서는 끝이 없는 불만을 보실 수 있고, 소스를 보시면 내부적으로 utf지원이 되지 않는 서버에서 UTF8을 '제대로' 사용하기 위하여 얼마나 고민했는지 보실 수 있습니다 ㅠ_ㅠ
5. 아파치, mysql에서 독립적인 구조가 되는 것이 1.1 이후의 로드맵에 있습니다. DB접근의 추상화와 IIS등의 웹서버 환경에서의 동작이 다음 목표입니다^^

포럼으로 이동: 아이디어 및 기능 제안

3,515 inureyes이 작성한 답글

(2 답글들, 아이디어 및 기능 제안에 작성)

서드파티 프로그램 및 프로젝트 지원 링크를 추가해 주세요 ~

포럼으로 이동: 아이디어 및 기능 제안

3,516 inureyes이 작성한 답글

(9 답글들, 아이디어 및 기능 제안에 작성)

ditto 작성:

굳이 합치지 않고도 조인 쿼리를 이용해서 같이 받아올 수 있을 것 같습니다만... smile
정렬은 시간 순서로 해야겠지요? 그렇다면 시간 필드에 인덱스를 걸어야 겠군요.

넵 충분히 가능합니다^^ (단 join의 시간 복잡도가 좀 높죠? 흐흐)

관리자 화면에서 선택할 수 있도록 하고 그에 따라 출력하도록 만들면 되겠군요. 단, 이 경우 스킨이 문제가 되겠네요^^
1.1 다음의 1.5로 이관하도록 하겠습니다 smile 혹시 안정적으로 직접 구현해 주시면 코드 받아 QA하고 1.1에 들어갈 수도 있어요 ㅎㅎ

포럼으로 이동: 아이디어 및 기능 제안

3,517 inureyes이 작성한 답글

(3 답글들, 잡담하기에 작성)

전 오늘 올라왔습니다 smile

올라오는길은 하나도 안 밀리더군요. 포항 - 서울 딱 네시간 오 분 끊더라구요^^

포럼으로 이동: 잡담하기

3,518 inureyes이 작성한 답글

(4 답글들, 잡담하기에 작성)

라지엘님 숙제.

지금까지 밀린 글 다 읽으시죠. 그리고 앞으로 1일 20분을 들여 모든 글을 다 읽기 바랍니다. smile

포럼으로 이동: 잡담하기

3,519 inureyes이 작성한 답글

(16 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

F5 신공과 ctrl - F5 신공을;

(무슨 무협지같군요 하하)

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

3,520 inureyes이 작성한 답글

(2 답글들, 티스토리(TiStory.com)에 작성)

예전에 논의된 적이 있고, 그에 따라 여러 의견이 오갔고 관련하여 다른 방식으로 1.1에 반영도 되었습니다 smile

검색의 생활화~

포럼으로 이동: 티스토리(TiStory.com)

3,521 inureyes이 작성한 답글

(10 답글들, 공지사항에 작성)

저 참석합니다 smile

포럼으로 이동: 공지사항

3,522 inureyes이 작성한 주제

(10 답글들, 공지사항에 작성)

1.1에 관련된 다양한 이슈를 의논하고자 TNF 임시 기술회의를 엽니다. TNF의 일원이면 누구나 참여하실 수 있습니다.
이번주 토요일 (8월 5일) 오후 2시 30분에 TNC 사무실 회의실에서 열릴 예정입니다. 점심을 드시고 오시면 됩니다.

논의하고자 하는 주제는 1.1 알파버전 배포 관련한 여러 사항과 베타 페이즈로의 이행에 관한 논의, 1.1 이후의 차기 버전의 로드맵에 관한 논의, 서드파티 프로그램 지원과 태터 메인페이즈 개편 관련 논의사항, 태터사이트 운영 방안 등입니다.

참여하실 분들은 수요 조사를 위하여 아래 댓글 부탁드립니다. smile

포럼으로 이동: 공지사항

3,523 inureyes이 작성한 답글

(14 답글들, 아이디어 및 기능 제안에 작성)

lacovnk 작성:

[1. 파일명 자동 생성 문제

한글 파일명은 urlencode를 이용해서 처리하면 됩니다. 이를 이용해서 원래 파일명 대로 저장하고, 실제 웹페이지에 보여줄 때에도 실제 파일명을 반영하도록 하는 것이 어떨까요?

이전에도 관련 이야기를 나눈 적이 있었습니다^^

원파일 이름을 바꾸어 저장하는 이유는 단순히 귀찮아서는 아닙니다. 내장된 encodeURI함수로 한글파일명 파싱해서 저장한다거나 해도 되겠지만, 좀 더 근본적으로 언어권 독립적인 저장 방법이 필요합니다. 태터툴즈가 UTF 지원이 되지 않는 수많은 국가의 다양한 서버 환경에서도 원활하게 돌아가기 위해서 이대로 간다고 생각하시면 됩니다^^

현재는 디비에 원파일명을 저장하고, 다운로드 등의 링크를 걸 경우에는 원래 파일명으로의 다운로드가 가능하도록 지원하고 있습니다. 그리고 덧붙여, 플러그인 등에서 특정 파일들을 모아 갤러리 기능을 만든다거나 다운로드 서비스를 만들 경우 그때마다 파일 리스트 전체를 파싱하는 것도 비효율적이기 때문에 현재의 방식이 가장 최적이라고 판단하고 있습니다 smile

포럼으로 이동: 아이디어 및 기능 제안

3,524 inureyes이 작성한 답글

(5 답글들, 잡담하기에 작성)

네이버의 지역 정보를 구글맵의 위치와 딱 한 번 1대1 대응만 시킨 다음에 이후엔 그냥 제한없는 구글맵을 사용하면 될겁니다 smile

포럼으로 이동: 잡담하기

3,525 inureyes이 작성한 답글

(5 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

r1014 에서 될겁니다 smile

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)