이 내용은 2004/04/19 기준으로 쓰여졌습니다. 최신 내용은 본가에서 얻으실 수 있습니다.

차례

개요
SHIORI/2.x 의 인터페이스
보안
스테이터스 코드
앨리어스(alias)

개요

Shiori 는 Ghost의 핵심적 요소이고, 이 부분의 처리 여부가 인격의 거의 모두가 된다.

home
 +-ghost
    +-naru
       +-ghost
          +-master
             +-shiori.dll

SHIORI/2.x 의 인터페이스

SHIORI/2.0 은 2.x 계의 기초적인 프로토콜을 정의 한다.

인수/반환값의 수수는 모두 Global Memory 로 한다. GMEM_FIXED 로 데이터를 받아, 메모리 핸들을 Free 시키고, 데이터의 길이를 len 을 사용하여 데이터를 취득, 반환값 작성 후 len 에 적정인 값을 다시 넣어, GMEM_FIXED 로 돌려준다.

{{{ * 함수 선언 extern "C" declspec(dllexport) HGLOBAL cdecl request(HGLOBAL h, long *len); function request(h: hglobal; var len: longint): hglobal; cdecl; export; }}}

모든 리퀘스트는 request 라고 하는 유일한 함수를 통해 행해진다.

리퀘스트 헤더는 HTTP 나 SSTP 의 형식과 거의 동일하다. 모든 행은 CR+LF 로 구분되어 1행째에 명령과 버전, 2행 이후에 임의의 수의 헤더가 배치되어 최종적으로 CR+LF 2개로 종료된다.

DLL 로드시 및 언로드시에 다음의 함수가 불려진다.

extern "C" __declspec(dllexport) BOOL __cdecl load(HGLOBAL h, long len);
function load(h: hglobal; len: longint): boolean; cdecl;

extern "C" __declspec(dllexport) BOOL __cdecl unload();
function unload: boolean; cdecl;

load 의 제1 인수에 DLL 의 디렉토리 경로를 건네받는다. Shiori 가 고유의 데이터 파일등을 가지는 경우는, 여기에서 현재의 디렉토리를 취득해, 그곳에서 자신의 데이터 파일을 읽어들여야 한다.

캐릭터 라인이 필요없는 경우에서도 함수내에서 핸들을 Free시키지 않으면 안 된다.

load 가 성공할 경우 Shiori 는 TRUE 를, load 가 실패할 경우 Shiori 는 FALSE 를 돌려주어야 한다.

SHIORI/2.0

참고: GET과 NOTIFY의 차이점

GET은 클라이언트 (본체)가 Shiori로부터 정보를 필요로 할 때 사용되며, Shiori는 그에 해당하는 정보를 돌려주거나 필요가 없을 경우 정보가 없다고 알려주어야 한다. NOTIFY는 클라이언트가 Shiori에게 무언가를 알려 주려 할 때 사용되며, Shiori는 클라이언트에게 스테이터스 코드 이외의 어떤 것도 보내주면 안 된다.

GET Version

GET Version SHIORI/2.0
Sender: Nobody
Charset: Shift_JIS

----

SHIORI/2.0 200 OK

클라이언트는 여기서 얻은 버전 정보를 사용하여(필요가 있으면) 리퀘스트의 레벨을 변화 시킨다. (주: 여기서 Shiori가 처리가능한 SHIORI/2.x 리퀘스트의 최대 버전을 알려주어야 한다. 일례로 SHIORI/2.5 까지 가능하다면 SHIORI/2.5 200 OK으로. 예전에는 GET Version 리퀘스트만은 load/unload가 불리기 전에도 처리가능해야만 하다는 내용이 있었던 것 같은데..)

NOTIFY OwnerGhostName

NOTIFY OwnerGhostName SHIORI/2.0
Sender: Nobody
Ghost: 사쿠라
Charset: Shift_JIS

----

SHIORI/2.0 200 OK

클라이언트가 서버에 일방적으로 정보를 통지하는 리퀘스트가 NOTIFY 이다. 2.0 에서는 NOTIFY OwnerGhostName이 사용되고 있다.

인수

Ghost
- 클라이언트에서 동작하고 있는 고스트명

GET Sentence

GET Sentence SHIORI/2.0
Sender: User
Charset: Shift_JIS
Sentence: 안녕.

----

SHIORI/2.0 200 OK
Sender: First
BalloonOffset: 0,0[1]0,0
Sentence: \0\s0안녕. \e

인수

Sentence
- 이야기의 내용
BalloonOffset
- 말풍선 위치 오프셋(생략 가능) 사쿠라-케로 순으로 바이트 코드 0x01로 구분된다.

클라이언트가 서버에 스크립트를 요구하는 리퀘스트가 GET Sentence 이다. 이것은 기본적으로 「누군가가 이야기 해 왔다」라는 것을 나타낸다. SHIORI/2.0 에서는 User 로부터의 GET Sentence 가 실장되어 있다.

GET Word

GET Word SHIORI/2.0
Sender: materia
Type: \ms
Charset: Shift_JIS

---

SHIORI/2.0 200 OK
Word: 사쿠라

클라이언트가 서버에 단어(스크립트의 단편)를 요구하는 리퀘스트가 GET Word 이다.

인수

Type
- 취득해야할 단어의 타입

Type 헤더에 건넬 수 있는 캐릭터 라인은 다음과 같습니다.

\ms
- 명사 - 사람
\mz
- 명사 - 무기물
\ml
- 명사 - 집합
\mc
- 명사 - 회사명
\mh
- 명사 - 상점명
\mt
- 명사 - 기술
\me
- 명사 - 음식
\mp
- 명사 - 지명
\m?
- 명사 - 비한정
\dms
- 품사가 복수 연결된 약간 긴 명사 (명사구 등)

GET Status

GET Status SHIORI/2.0
Sender: Nobody
Charset: Shift_JIS

---

SHIORI/2.0 200 OK
Status: 0,0,0,0,0,0

클라이언트가 서버에 고스트의 현재 정보를 요구하는 리퀘스트가 GET Status 입니다.

인수

Status
- 순서대로 Neuron, NeuronM, NeuronK, NeuronD, NeuronE, Synapse 이 값은 AI 의 스펙(명세서)을 그래프로서 표시할 때에 사용됩니다. 그래프를 표시하는 의지가 없으면 이 리퀘스트는 무시해도 상관없습니다.
  (주 1: 각 값은 초기에는 어떤 의미를 가지고 있었으나 현재는 거의 잊혀져 있습니다. 대부분의 Shiori모듈에서도 아무 값이나 보내주고 있고요. 단지, 다음 내용이 정설이라 믿어지고 있습니다. 출처 - プログラム談義用Phase 2.0의 180번 글 중에서)

Neuron ... 단어의 갯수 (NeuronM,K,D,E 의 총합)
NeuronM ... 명사의 갯수
NeuronK ... 형용사의 갯수
NeuronD ... 동사의 갯수
NeuronE ... 그 외의 단어의 갯수
Synapses ... 단어 체인(문장)의 갯수

(주 2: Status 값은 12개로도 표현되기도 합니다. 0,0,0,0,0,0,0,0,0,0,0,0 식으로 말이죠. 이 때 뒤의 6개 값은 앞의 6개 값의 변화량이라고 알고 있습니다.)

반응

리퀘스트가 데이터를 요구하는 것이었던 경우 (곧, GET일 경우), 서버는 스테이터스 코드에 이어 필요한 헤더를 돌려 보낸다. 돌려주어야 할 헤더는 리퀘스트에 따라서 달라, 그것은 SHIORI/2.1 이후의 사양에서도 각각 정의 된다.

예시

GET Sentence SHIORI/2.0
Sender: materia
Charset: Shift_JIS

----

SHIORI/2.0 200 OK
Sender: First
BalloonOffset: 0,0[1]0,0
Sentence: \0\s0‥‥. \e

Sender
- Shiori 의 ID
BalloonOffset
- 말풍선 위치 오프셋(생략 가능)
Word
- 단어, 혹은 스크립트 단편
Sentence
- 스크립트 (SakuraScript)

BalloonOffset는 생략 가능한 특수한 헤더로, 바이트값 1 과 콤마로 구분되어 왼쪽으로부터 sakura.balloonoffset.x, sakura.balloonoffset.y, kero.balloonoffset.x, kero.balloonoffset.y 를 표현한다. 여기서 설정된 말풍선 오프셋값은 쉘에 설정한 말풍선 오프셋값을 오버라이드(override) 한다. (즉 고스트가 쉘의 영역에까지 진입 하고 있어 매우 특수함).

SHIORI/2.1

SHIORI/2.2 이후의 프로토콜에 흡수, 사용되지 않습니다.

SHIORI/2.2

SHIORI/2.2 는 Shiori 에 범용적인 이벤트를 보내는 리퀘스트이다. 이벤트는 기본적으로 Materia 본체가 동작 상황에 따라 발행하지만, SSTP NOTIFY/1.0 및 SAKURA API/1.3 을 이용해 외부로부터 발생 시키는 것도 할 수 있다. 이러한 리퀘스트는 그 안전성이 SecurityLevel 에 의해 구별된다(후술).

이 문서에서는 Shiori 로서의 이벤트의 해석의 방법(수신)만을 취급한다. 송신에 대해서는 SSTP NOTIFY/1.0 (SpecSstp) 및 SAKURA API/1.3 (SpecSakuraApi) 의 사양서를 참조할 것.

Get Sentence SHIORI/2. 2
Sender: Nobody
Event: OnDisplayChange
Reference0: 32
Reference1: 1280
Reference2: 1024
Charset: Shift_JIS

Event 헤더가 이벤트의 식별자를 표현한다. 이것은 반드시 unique 한 캐릭터 라인이고, 일정하여야 하며, 어떤 하나의 뜻을 가지고 있어야 한다.

Reference 헤더가 이벤트의 부수 정보(인수)를 표현한다. 예를 들면 상기의 예에서는 화면 해상도의 변화 이벤트인 OnDisplayChange 의 인수에 색심도와 해상도가 건네받고 있다. Reference 는 최대로 8개 (Reference0 - Reference7 까지) 정의 된다.

아래에, 본체 통지의 이벤트의 일람을 나타낸다. (곧, Event 헤더의 값이다)

본체 통지 이벤트

타이밍 통지 이벤트

OnFirstBoot

처음 기동했다 (주: 고스트 설치 후 최초 기동시 발생)

인수

Reference0
- Vanish 카운트 ※Vanish 카운트 - 현 환경으로 그 고스트가 Vanish (소멸)된 통산 회수.

OnWindowStateMinimize

최소화되었다

OnWindowStateRestore

최소화 상태로부터 복원되었다

OnBoot

기동했다 (주: 본체가 해당 고스트로 종료 후 다음 번에 본체 실행 시 같은 고스트가 기동하며 발생)

OnClose

종료를 지시받았다 ※지시받는 것에 지나지 않고 종료할지 어떨지는 Shiori 의 판단에 맡기기 때문에 주의 (주: \- 스크립트가 없으면 종료하지 않는다.

OnTeachStart

Teach 대화창이 열렸다

변환 이벤트

OnGhostChanging

자신 이외의 고스트로의 변환을 지시받았다 (주: 고스트 변환시 이전 고스트에게 마지막으로 발생)

인수

Reference0
- 다음 고스트의 이름
Reference1
- 변환 방법
  - manual
    - 수동으로 교체되었다
  - automatic
    - (시스템등에 의해) 자동으로 교체되었다

OnGhostChanged

자신이 고스트가 되었다 (주: 고스트 변환시 다음 고스트에게 처음 발생)

인수

Reference0
- 이전 고스트의 이름

OnShellChanging

쉘 변환을 지시받았다 (주: 한 고스트가 여러 쉘을 소유하고 있을 경우 쉘을 바꾸기 전에 발생)

OnShellChanged

쉘이 바뀌었다 (주: 쉘이 바뀌고 나서 처음 발생)

인수

Reference0
- 선택된(다음) 쉘의 이름

소멸 이벤트

OnVanishSelecting

소멸 통고를 받았다

OnVanishSelected

소멸 확인 다이얼로그에서 YES 가 선택되었다

OnVanishCancel

소멸 확인 다이얼로그에서 NO 가 선택되었다

OnVanishButtonHold

만류할 수 있었다

OnVanished

직전의 고스트가 소멸을 지시받아 자신에게 바뀌었다

인수

Reference0
- 직전의 고스트의 이름

시간 이벤트

OnSecondChange

현재초가 변화했다 (주: 이 이벤트가 평상시의 대화 출력에 쓰인다)

인수

시간 이벤트의 인수 참조

OnMinuteChange

현재분이 변화했다 (주: 이 이벤트 역시 평상시의 대화 출력에 쓰이지만 잘 사용되지 않는다)

인수

시간 이벤트의 인수 참조

시간 이벤트의 인수 (공통)

Reference0
- 연속 기동 시간(hour)
Reference1
- 고스트가 화면 밖에 나가 보이지 않는지 여부 플래그(bool ※0)
Reference2
- 사쿠라측(본체)과 케로측(대화상대)가 겹쳐 있는지 여부 플래그(bool ※0)
Reference3
- cantalk 플래그(bool ※0)

※0. false = 0, true = 1

양이벤트는 돌려준 스크립트가 표시할 수 없는(이 경우, 해당 스크립트는 무시된다) 상태에서도 발생하지만, 그 때문에 표시할 지 표시하지 않을 지 모르는 스크립트를 고스트가 모르는 동안에 어둠에 매장시켜 버릴 가능성이 있다. 그러한 문제를 막기 위해서 cantalk 플래그가 존재한다. cantalk 플래그는 돌려준 스크립트가 본체에 읽혀지는 것인가 버려지는 것인가를 표현한다. 1 이라면 읽혀지고 0 이라면 읽혀지지 않는다.

표면 이벤트

OnSurfaceChange

표면이 바뀌었다 (예: 1번 표면에서 2번 표면으로)

인수

Reference0
- 사쿠라측에서 현재 표시중인 표면의 번호
Reference1
- 케로측에서 현재 표시중인 표면의 번호

OnSurfaceRestore

표면을 기본 표면(고스트에 의해 다르다. First Ghost 의 경우, 사쿠라는 0, 우뉴는 10)으로 돌려야 할 타이밍이 왔다

※타이밍을 전하는 것만으로 돌릴지 어떨지는 Shiori 가 판단하므로 주의

인수

Reference0
- 사쿠라측에서 현재 표시중인 표면의 번호
Reference1
- 케로측에서 현재 표시중인 표면의 번호

마우스/키보드 이벤트

주로 만지작 이벤트, 클릭 이벤트, 메뉴 표시 등에 사용

OnMouseMove

마우스가 이동했다

인수

마우스 이벤트의 인수 참조

OnMouseClick

마우스가 왼쪽 클릭되었다

인수

마우스 이벤트의 인수 참조

OnMouseDoubleClick

마우스가 더블 클릭 되었다

인수

마우스 이벤트의 인수 참조

OnMouseWheel

마우스 휠이 회전했다

인수

마우스 이벤트의 인수 참조

마우스 이벤트의 인수 (공통)

Reference0
- 마우스 커서의 x 좌표(로컬 좌표)
Reference1
- 마우스 커서의 y 좌표(로컬 좌표)
Reference2
- 마우스 휠의 회전양 및 회전 방향
Reference3
- 이벤트의 오너(0 : Sakura / 1 : Kero)
Reference4
- 판정 위치 식별자

판정 위치 식별자는 쉘에 의해 자유롭게 정의 된다. 가장 표준적인 것은 Head, Face, Bust 등.

OnKeyPress

키보드가 눌러졌다

인수

Reference0
- 눌러진 키의 식별자(키보드에 쓰여진 문자 그대로)

인스톨 이벤트

SpecInstall 참조

OnInstallBegin

인스톨이 개시되었다

OnInstallComplete

인스톨이 정상 종료했다

인수

Reference0
- 인스톨 된 오브젝트의 식별자
Reference1
- 인스톨 된 오브젝트의 이름
Reference2
- with balloon 등 , 오브젝트가 2개 이상 있을 때, 다음의 오브젝트의 이름
식별자
- shell/ghost/balloon/plugin 4종류

OnInstallFailure

인스톨이 이상종료(ABEND) 했다

인수

Reference0
- 실패의 이유
  - unlha32
    - unlha32 로드 실패
  - invalid type
    - install.txt 가 부정확함

OnInstallRefuse

인스톨 하는 파일이 다른 고스트를 지명하고 있었다 (예: 마유라에게 나루의 쉘을 설치하려 했을때)

인수

Reference0
- 지명되어 있는 고스트의 이름

드롭 이벤트

OnFileDropping

파일이 Drag-and-Drop 되었다(파일에 대한 처리전)

인수

파일 드롭 이벤트의 인수 참조

OnFileDropped

파일이 Drag-and-Drop 되었다(파일에 대한 처리 종료)

인수

파일 드롭 이벤트의 인수 참조

OnDirectoryDrop

디렉토리가 Drag-and-Drop 되었다

인수

파일 드롭 이벤트의 인수 참조

OnWallpaperChange

(그림 파일의 Drag-and-Drop 에 의해) 벽지가 변경되었다

인수

파일 드롭 이벤트의 인수 참조

파일드롭 이벤트의 인수 (공통)

Reference0
- 파일/디렉토리명(풀 패스)
Reference1
- 파일/디렉토리명(풀 패스)

OnURLDropping

URL이 드롭 되었다(아직 로컬에 파일은 없다)

인수

Reference0
- URL

OnURLDropped

URL이 드롭 되었다(다운로드는 종료해 이미 로컬에 파일이 있다)

인수

Reference0
- 다운로드한 파일의 로컬 머신상에서의 절대 패스

BIFF 이벤트 (메일 관련)

OnBIFFBegin

메일 체크가 개시되었다

인수

Reference2
- 체크하는 서버의 이름 (주: $/!\$ Reference 0,1에 대한 내용이 원본에 없음. 확인 필요)

OnBIFFComplete

메일 체크가 성공했다

인수

Reference0
- spool 되어 있는 메일의 통수
Reference1
- spool 되어 있는 메일의 바이트수
Reference2
- 체크하는 서버의 이름
(주: $/!\$ Reference3 원본에 없음. 체크 필요)
Reference4
- 전메일의 top result
Reference5
- list result
Reference6
- uidl result

OnBIFF2Complete

메일 spool수가 증가했다

인수

Reference0
- spool 되어 있는 메일의 통수
Reference1
- spool 되어 있는 메일의 바이트수
Reference2
- 체크하는 서버의 이름
Reference3
- 전번으로부터 증가한 메일의 통수
Reference4
- 전메일의 top result
Reference5
- list result
Reference6
- uidl result
- Reference4-6 는 아래와 같은 포맷을 베풀어진 캐릭터 라인으로서 건네받는다.
  - [1] - 바이트값 1
  - [2] - 바이트값 2

reference4 - 아[1]이[1]우[1]에[1][2]카[1]키‥‥
reference5 - 0 1024[1]1 1024[1]‥‥
reference6 - 0 uidl0[1]1 uidl1[1]‥‥

OnBIFFFailure

메일 체크가 실패했다

인수

Reference0
- 실패 사유
(주: $/!\$ Reference1 원본에 없음. 체크 필요)
Reference2
- 체크하는 서버의 이름
실패 사유
- timeout
  - 타임 아웃
- kick
  - 인증했지만 거부되었다 (인증 실패)
- defect
  - 유저의 설정에 잘못이 있다

갱신 이벤트

SpecNetworkUpdate 참조

OnUpdateBegin

네트워크 갱신이 개시되었다

OnUpdateReady

네트워크 갱신의 준비가 갖추어졌다

인수

Reference0
- 지금부터 갱신을 하는 파일의 총 갯수

※OnUpdateBegin 는 갱신 지시 직후 바로 발생한다. materia 는 그 후 갱신해야할 파일이 있는지 여부를 조사해, 있으면 OnUpdateReady 를 발생시켜 실제의 갱신 작업에 들어간다. 없었던 경우는 OnUpdateComplete 로 그대로 종료한다.

OnUpdateComplete

네트워크 갱신이 성공했다

인수

Reference0
- 성공/실패 사유
Reference1
- 콤마로 구분된 갱신된 파일명의 리스트
  - none
    - 갱신해야 할 파일이 없었다

OnUpdateFailure

네트워크 갱신이 실패했다

인수

Reference0
- 성공/실패 사유
  - timeout
    - 타임 아웃
  - md5 miss
    - MD5 불일치
  - 404 등
    - 그 현상 코드로 실패 (주: HTTP프로토콜의 에러번호입니다)

OnUpdate.OnDownloadBegin

파일의 다운로드가 개시되었다

인수

Reference0
- 다운로드하는 파일의 이름
Reference1
- 갱신해야할 파일의 리스트 중에서의 현재 위치(position)
Reference2
- 갱신해야할 파일의 총 갯수(max)

OnUpdate.OnMD5CompareBegin

MD5 (에러 체킹 코드)의 비교가 개시되었다

OnUpdate.OnMD5CompareComplete

MD5 가 일치했다

OnUpdate.OnMD5CompareFailure

MD5 가 일치하지 않았다

인수

Reference0
- 비교하는 파일의 이름
Reference1
- 올바른 MD5 값
Reference2
- 비교하는 파일의 MD5 값

SNTP 이벤트 (시각 맞춤 관련)

OnSNTPBegin

시각 맞춤이 개시되었다

OnSNTPCompare

서버의 시계의 값과 로컬 머신의 시계의 값의 비교가 개시되었다

OnSNTPCorrect

로컬 머신의 시계를 서버의 시계에 맞추었다

OnSNTPFailure

시각 맞춤에 실패했다

인수

Reference0
- 접속처 서버
Reference1
- 콤마로 구분된 정확한(SNTP 서버측의) 시각
- year, month, day, hour, minute, second 의 순서
Reference2
- 콤마로 구분된 현재의 (SNTP 클라이언트 - 로컬 머신 - 측의) 시각
- year, month, day, hour, minute, second 의 순서
Reference3
- 어긋난 시간(second)

헤드라인 센스 이벤트

OnHeadlinesenseBegin

헤드라인 센스가 개시되었다

인수

Reference0
- 대상 사이트명
Reference1
- 대상 URL

OnHeadlinesense.OnFind

헤드라인 센스의 결과를 읽어들이라고 지시받았다

인수

Reference0
- 대상 사이트명
Reference1
- 대상 URL
Reference2
- OnFind 의 페이지 지시자 ※1
Reference3
- 헤드라인 데이터 본체(벚꽃 스크립트 단편)

Reference2 이후는 OnFind시만 건네받는다. OnFind 지시자는 First, First and Last, Last, Next 의 4개로, 각각 첫 페이지, 첫 페이지이지만 뒷장이 없다 (곧, 한 장 뿐이다), 마지막 페이지, 그리고 중간 페이지를 표현한다.

OnFind 이벤트에서 식별자가 없는 선택을 하면, 그것이 페이지 넘김의 기능을 한다.

{{{ * 반응시 SakuraScript 예제 ...(헤드라인 데이터)...\n\n\q0[][다음의 페이지로] }}}

OnHeadlinesenseComplete

헤드라인 센스가 정상 종료했다

헤드라인 센스의 성공은 헤드라인을 읽을 수 있는가의 여부를 의미하므로, Complete 는 취득에 성공했지만 갱신이 없었던 경우만 통지된다.

인수

Reference0
- 성공/실패의 사유
- no update
  - 갱신이 없었다

OnHeadlinesenseFailure

헤드라인 센스가 실패했다

인수

Reference0
- 성공/실패의 사유
- no update
  - 갱신이 없었다
- can't download
  - 헤드라인을 다운로드할 수 없었다
- can't analyze
  - 헤드라인을 다운로드했지만, 유효한 헤드라인을 취득할 수 없었다

노래 이벤트

OnMusicPlay

곡의 재생이 시작되었다

인수

Reference0
- 곡명(아티스트명등의 부가 정보가 붙어 있을 가능성 있음)

(주: OnMusicPlay는 단지 곡의 재생이 되었다는 표시이지 곡에 가사가 첨부되어 있는지의 여부는 아니라는 것에 주의. 보통 OnMusicPlay에서는 "(곡명)이라는 것을 듣고 있는데 뭔지 잘 모르겠어" 등의 대화를 무조건 시도하고 만약 가사가 있어서 가사가 SSTP로 보내진다면 해당 대화가 자동으로 사라지는 (SSTP는 일반 대화를 무시하고 출력된다) 효과를 사용해 마치 고스트가 해당 노래에 대해 알고 있다는 착각을 하도록 처리한다)

선택지 이벤트

OnChoiceSelect

선택지가 선택되었다

인수

Reference0
- 선택된 선택지가 가지는 식별자

OnChoiceTimeout

타임 아웃 (유저가 일정 시간 동안 선택하지 않음) 했다

인수

Reference0
- 타임 아웃 한 스크립트

예외(에러) 이벤트

OnSSTPBreak

SSTP가 브레이크 되었다

인수

Reference0
- 예외가 일어난 스크립트

마스터 이벤트

SpecNetworkUpdate, SpecInstall 참조

OnUpdatedataCreating

updates2.dau 를 작성하기 시작했다

OnUpdatedataCreated

updates2.dau 의 작성이 끝났다

OnNarCreating

NAR Ghost elements 의 작성이 개시되었다

OnNarCreated

NAR Ghost elements 의 작성이 종료했다

인수

Reference0
- nar 로 작성되는 오브젝트의 이름
Reference1
- nar 의 출력 파일명
Reference2
- type 식별자 (SpecInstall)

분류 불가

OnNetworkHeavy

상대 서버가 시간내에 응답하지 않았다

OnDisplayChange

데스크탑의 해상도/색심도가 변화했다

인수

Reference0
- 변화 후의 색심도(bpp: 픽셀당 비트수)
Reference1
- 변화 후의 해상도(width: 가로)
Reference2
- 변화 후의 해상도(height: 세로)

OnSSTPBlacklisting

최종 클라이언트의 블랙 리스트행이 지시받았다

인수

Reference0
- 최종 클라이언트의 IP 주소

OnRecommendsiteChoice

「추천」메뉴로부터 사이트가 선택되었다

인수

Reference0
- 선택된 사이트의 명칭
Reference1
- 선택된 사이트의 URL

Reference 의 수에 대하여

Reference 엔트리의 최대수는 SHIORI/2.2 에서는 8입니다(Reference7까지).

OnClose 등 매우 기초적인 것을 제외하고, 대부분의 이벤트는 기본적으로 무시할 수가 있습니다(무반응, 말하지 않는다). 무시하는 경우는 리퀘스트에 대해 204 No Content 스테이터스를 돌려주세요.

SHIORI/2.3b

SHIORI/2. 3 은 Shiori(고스트) 끼리의 대화를 실현하기 위한 방법입니다.

NOTIFY OwnerGhostName

Shiori 클라이언트는 SHOIRI 서버에 대해 부정기적으로 NOTIFY 리퀘스트를 합니다.

NOTIFY OwnerGhostName SHIORI/2.3
Sender: materia
Ghost: 사쿠라
Charset: Shift_JIS

NOTIFY OwnerGhostName은 현재 접속중인 Shiori 클라이언트로 동작하고 있는 고스트명 (Shiori를 사용하고 있는 고스트명)에 대한 통지입니다. 이 정보는 기동시나 고스트 변환시에 통지됩니다.

NOTIFY OtherGhostName

NOTIFY OtherGhostName SHIORI/2.3
Sender: materia
GhostEx: 나루[1]0[1]1
GhostEx: 마유라[1]0[1]1
....
..
Charset: Shift_JIS

※[1] 은 바이트값 1 ※식별자가 GhostEx 인 것은 과거 호환성 때문

NOTIFY OtherGhostName은 현재 통신 가능한 상태로 기동하고 있는 자신 이외의 고스트의 이름에 대한 통지입니다. 존재하는 수만 GhostEx 헤더가 쌓입니다. 자신 이외에 고스트가 없는 경우 GhostEx 헤더는 하나도 부가되지 않습니다.

GhostEx 헤더에는 3개의 정보가 포함되어 왼쪽으로부터 고스트명, 그 고스트의 사쿠라측의 현재의 surface ID, 케로측의 surface ID 를 나타내고 있습니다.

Shiori는 이 정보를 이용해 앞으로 누구에게 이야기할까를 결정 할 수 있습니다.

반응시의 To/Age/Reference 헤더

To 헤더로 상대 고스트명을 지정하는 것으로써, 그 상대(가 가지는 Shiori)에게 이야기할 수가 있습니다.

SHIORI/2.3 200 OK
Sender: 사쿠라
To: 나루
Age: 0
Sentence: \0\s0안녕. \e
Reference0: N/A
Charset: Shift_JIS

To 및 Age 헤더가 올바르게 지정될 경우, 클라이언트는 통상의 대사 발언에 더하여 Sentence 부를 Direct SSTP (COMMUNICATE/1. 2)를 이용해 To 가 식별하는 다른 Shiori 클라이언트에 송신합니다. (SpecSstp, SpecDirectSstp 참조)

또, 이것 외에, Refernce 헤더를 이용해 상대 클라이언트에 임의의 추가 정보를 줄 수가 있습니다.

사용 할 수 있는 Reference 헤더는 최대 8(Reference7 까지)입니다. 내용에 대해서 규약은 없습니다. 추가 정보가 완전히 필요없는 경우 이 헤더는 생략 할 수 있습니다.

GET Sentence

Direct SSTP 를 수신한 클라이언트는 Shiori 에 GET Sentence 리퀘스트를 합니다.

GET Sentence SHIORI/2.3
Sender: 사쿠라
Sentence: \0\s0안녕. \e
Age: 0
Surface: 0,10
Reference0: N/A
Charset: Shift_JIS

----

SHIORI/2.3 200 OK
Sender: 나루
To: 사쿠라
Age: 1
Sentence: \0\s0아-. \w8\w8안녕. \e
Surface: 0,10
Reference0: N/A
Charset: Shift_JIS

통상의 GET Sentence 리퀘스트와 다른 곳은, Age 헤더가 있는 것으로, 이야기해 온 상대가 다른 Shiori(고스트)이고, Sender 가 Nobody 는 아니고 고스트명이라는 두 가지 입니다.

이 리퀘스트에 대해서 대답을 하는 경우는, Sender 로 건네받은 이름(여기에서는 「사쿠라」)을 To 로 지정해 반응을 돌려줍니다. 대답은 위와 같은 루트를 통해 다시 상대의 Shiori 에 통지됩니다.

반응은 하지만 대답은 하지 않는 경우는 To를 생략 합니다.

대답을 하는 경우, Shiori 는 반드시 Age 를 1 증가(increment) 시켜 주세요. 이 값은 주로 언제 회화를 중지할까를 결정하기 위해서 이용됩니다.

SHIORI/2.4

SHIORI/2.4 는 Shiori(고스트)에 대화식으로 정보를 학습 시키기 위한 리퀘스트입니다.

TEACH

{{{ * 1회째의 TEACH TEACH SHIORI/2.4 Word: 갓츠 이시마츠 }}}

우선 클라이언트가 TEACH 리퀘스트를 보냅니다.

311 Not Enough

{{{ * 1회째의 TEACH에 대한 반응 SHIORI/2.4 311 Not Enough Sentence: \h\s0갓츠 이시마츠는 무엇입니까? \e }}}

대부분, 단어의 이름 만으로 학습하기에는 너무 정보가 부족하므로, 311 Not Enough 를 돌려주어 추가 정보의 입력을 요구합니다.

클라이언트는 추가 정보를 Reference 헤더에 세트 해, 재차 TEACH 리퀘스트를 합니다.

{{{ * 2회째의 TEACH 및 반응 TEACH SHIORI/2.4 Word: 갓츠 이시마츠 Reference0: 인명

SHIORI/2.4 311 Not Enough Sentence: \h\s0관계 있는 말이라든가 뭐 있습니까? \e }}}

{{{ * 3회째의 TEACH 및 반응 TEACH SHIORI/2.4 Word: 갓츠 이시마츠 Reference0: 인명 Reference1: 위험

SHIORI/2.4 311 Not Enough Sentence: \h\s0다른 것은? \e }}}

이후, 필요한 정보가 갖추어질 때까지 이 주고받음을 반복합니다. 서버는 Sentence 로 안내하면서 필요한 정보가 갖추어질 때까지 311 을 돌려주어, 학습에 성공한 시점으로 200 을 돌려주세요.

Reference 헤더의 서수는 311 이 돌아갈 때마다 1 증가(increment) 됩니다. 상한은 없습니다.

200 OK

{{{ * 학습 완료. 더 이상 TEACH 발생하지 않음 SHIORI/2.4 200 OK Sentence: \h\s0학습했습니다. \e }}}

312 Advice

312 는 주로 해석할 수 없는 정보등이 입력되었을 때, 현재의 상태를 유지한 채로 안내만 할 때에 사용됩니다.

{{{ * 1회째의 TEACH에 대한 반응 SHIORI/2.4 311 Not Enough Sentence: \h\s0갓츠 이시마츠는 무엇입니까? \e }}}

여기서 클라이언트가 해석할 수 없는 문자를 돌려주었다고 합시다.

{{{ * 2회째의 TEACH 및 반응. 312 Advice 반응으로 3회째에 Reference0에 다시 내용이 넣어진다. TEACH SHIORI/2.4 Word: 갓츠 이시마츠 Reference0: 위험한 것

SHIORI/2.4 312 Advice Sentence: \h\s0‥‥\w8\w8‥‥? \e }}}}

이러한 대답을 하는 것으로 현재의 Reference0은 스택으로부터 제외해져 다음에 입력되는 데이터도 Reference0 으로 보내집니다.

312 로 무효화되는 것은 가장 새로운 Reference 헤더만입니다. 무효인 Reference1 에 대해서 312를 돌려줄 경우, 무효화되는 것은 Reference1 뿐으로, 이미 확정한 Reference0은 전번과 같은 것이 보내십니다.

이상과 같은 동작에 의해 Shiori 는 해석 불능인 데이터를 거부할 수가 있습니다.

SHIORI/2.5

SHIORI/2.5 는 단순한 캐릭터 라인 자원을 취득하기 위한 리퀘스트이다.

GET String

GET String SHIORI/2.5
ID: homeurl
Chrset: Shift_JIS

----

SHIORI/2. 5 200 OK
String: http://sakura.mikage.to/

Shiori는 ID 헤더로 지정된 식별자에 대응한 적절한 캐릭터 라인 혹은 캐릭터 라인의 형태를 취한 int/bool 값을 돌려준다.

정의가 끝난 ID 헤더는 다음과 같다. 특히 생략 가능이라고 표시되지 않는 한 모든 대답은 필수.

ID 헤더

homeurl

네트워크 갱신시에 기준 위치가 되는 URL. 예를 들면 http://sakura.mikage.to/updates2.dau 를 사용해 갱신을 하는 경우, homeurl 이 돌려주는 캐릭터 라인은

http://sakura.mikage.to/

sakura.recommendsites

본체 (사쿠라)측의 추천 사이트의 리스트. 리스트는 컬럼이 바이트값 1, 테이블이 바이트값 2로 구분된다. 컬럼은 왼쪽으로부터, 사이트명, URL, 배너 URL. 바이트값을 [1] [2] 와 표기할 경우, 일반적인 반환값은 이하와 같은 형태가 된다. 생략 가능.

(예)

`사쿠라미카게`	`http://sakura.mikage.to/`	`http://sakura.mikage.to/banner.png`
`2행째`	`http://sakura.mikage.to/`	`http://sakura.mikage.to/banner.png`

사쿠라미카게[1]http://sakura.mikage.to/[1]http://sakura.mikage.to/banner.png[2]2행째[1]

http://sakura.mikage.to/[1]http://sakura.mikage.to/banner.png

kero.recommendsites

케로 (상담역)측의 추천 사이트의 리스트. 서식은 본체측의 것과 같다. 생략 가능.

sakura.portalsites

본체측의 포털 사이트의 리스트. 서식은 추천 사이트와 같다. 생략 가능.

buttoncaption 계열

sakura.recommendbuttoncaption 사쿠라측 추천 사이트 버튼
kero.recommendbuttoncaption 케로측 추천 사이트 버튼
sakura.portalbuttoncaption 사쿠라측 포털 사이트 버튼
updatebuttoncaption 네트워크 갱신 버튼
vanishbuttoncaption 소멸 통고 버튼
readmebuttoncaption Readme (기본설명서) 표시 버튼

pop-up menu에 있어서의 각각의 버튼의 캡션 캐릭터 라인. 생략 가능.

vanishbuttonvisible

「소멸 통고」버튼의 화면표시 상태를 표현하는 bool 캐릭터 라인. 0 이 false, 그 외는 모두 true. 생략 가능.

username

유저의 이름. 혹은 통칭.

defaultleft 계열

sakura.defaultleft
kero.defaultleft

각각의 쉘의 「디폴트 위치」의 x 좌표. 화면 좌표계.

보안

SHIORI/2.2 는 SSTP 에 의해 작동 될 가능성이 있기 때문에, 보내져 온 이벤트를 신용 할 수 있을지 그렇지 않을지 판단할 필요가 생긴다. 이 판단에는 SecurityLevel 헤더를 이용한다.

SecurityLevel 헤더는 모든 리퀘스트에 반드시 부여된다.

GET Sentence SHIORI/2.2
Sender: materia
SecurityLevel: external
Charset: Shift_JIS

현재 정의 되어 있는 식별자는 다음과 같다.

local
- materia 본체, 고스트, 및 로컬 머신으로부터의 SSTP(신용 할 수 있다)
external
- 그 이외(반드시 신용할 수 없다)

이 레벨 통지에 Shiori 가 어떻게 반응하는지는 자유롭다. 즉, 레벨 통지가 있다고 해도 모든 Shiori 하부조직이 Secure 하다고 하는 보증은 완전히 없다.

스테이터스 코드

서버가 돌려주어야 할 현상 코드는 다음과 같습니다.

{{{ 2xx - 처리 완료

200 OK

정상적으로 종료했다

204 No Content

정상적으로 종료했지만, 돌려주어야 할 데이터가 없다

}}}

{{{ 3xx - 처리 완료, 추가 액션 요구

310 Communicate

- deprecated (SHIORI/2.1 더이상 사용 않음) -

311 Not Enough

TEACH 리퀘스트를 받았지만, 정보가 부족하다

312 Advice

TEACH 리퀘스트내의 가장 새로운 헤더가 해석 불능

}}}

{{{ 4xx - 리퀘스트 에러

400 Bad Request

리퀘스트 미비

}}}

{{{ 5xx - 서버 에러

500 Internal Server Error

서버내에서 에러가 발생했다

}}}

앨리어스(alias)

home
 +-ghost
    +-naru
       +-ghost
          +-master
             +-alias.txt

앨리어스(alias)를 설정하는 것으로, DLL 파일명에 원하는 이름을 사용할 수 있습니다.

alias.txt 의 포맷은 다음과 같습니다.

shiori, sakura.dll

예를 들면 위와 같이 기술하는 것으로, materia 는 shiori.dll 대신에 sakura.dll 을 읽습니다.

엔트리는 생략 가능합니다. 생략 할 경우는 디폴트값(shiori.dll)이 사용됩니다.

2004/04/19 현재 제가 잊어버린 것 포함 불확실한 것이 좀 있습니다. 언젠가는 고칠 예정 (퍽) -- whoami

CategorySpec

Nanika: SpecShiori2 (2008-08-10 19:56:16에 localhost가(이) 마지막으로 수정)