From 39ba3c7d19a3e14593e127f57c167cb1feccabb1 Mon Sep 17 00:00:00 2001 From: codercay Date: Thu, 24 May 2012 16:11:42 +0900 Subject: [PATCH 1/4] edit korean text naturally --- doc/guide/ko/rpc_responder.md | 46 ++++++++++++----------------------- 1 file changed, 16 insertions(+), 30 deletions(-) diff --git a/doc/guide/ko/rpc_responder.md b/doc/guide/ko/rpc_responder.md index c94c69fe..52bb3a72 100644 --- a/doc/guide/ko/rpc_responder.md +++ b/doc/guide/ko/rpc_responder.md @@ -1,40 +1,32 @@ # RPC Server-side Websocket Responder # RPC 서버사이드 웹소켓 Responder -The RPC Responder -allows you -to call functions on the server -from the browser over the websocket, -returning a response if requested. -RPC Responder는 당신이 브러우저의 웹소켓을 통해 서버의 함수들의 호출을 한 경우에 response를 반환 합니다. +The RPC Responder allows you to call functions on the server from the browser over the websocket, returning a response if requested. It is powerful when used in conjunction with [Request Middleware](https://github.com/socketstream/socketstream/blob/master/doc/guide/en/request_middleware.md). -It is powerful when used in conjunction with [Request Middleware](https://github.com/socketstream/socketstream/blob/master/doc/guide/en/request_middleware.md). -그것은 [Request Middleware](https://github.com/socketstream/socketstream/blob/master/doc/guide/en/request_middleware.md)와 함께 할때 강력합니다. +RPC Responder는 당신이 브라우저에서 웹소켓을 통해 요청에 서버에서 함수들이 호출되어 응답이 반환 하는 것을 허용합니다. 그것은 [Request Middleware](https://github.com/socketstream/socketstream/blob/master/doc/guide/en/request_middleware.md)와 함께 할때 강력합니다. To make a Remote Procedure Call from the browser use the `ss.rpc()` function. -브라우저에서 원격 프로시져 콜을 할수 있는 `ss.rpc()` 함수를 사용하세요. +브라우저에서 원격 프로시져 콜을 만들기 위해 `ss.rpc()` 함수를 사용하세요. Let's assume we want to return an array of the latest products in an online store. -우리가 온라인 스토어의 최근의 제품들의 배열을 반환 하고 싶다고 가정합니다. +우리는 온라인 스토어에서 최신 상품들의 배열을 하나 반환 하고 싶다고 가정합니다. We would want to call the following command from the browser: -브라우저에서 다음 명령을 호출 하도록 합시다. +브라우저에서 다음 명령을 호출합니다. ``` javascript ss.rpc('products.latest', function(result){ console.log('The latest products are:', result); }) ``` This command will be sent over the websocket and sent directly to the RPC Responder. But how will it know which function to call on the server? -이 명령은 웹소켓을 통해 전송되고 직접적으로 RPC Responder에게 전달 될 것입니다. +이 명령은 웹소켓을 통해 전송되고 직접적으로 RPC Responder에게 전달 될 것입니다. 하지만 서버에서 어떤 함수가 호출되었는지 어떻게 알 수 있을까요? -The RPC responder loads all commands in `server/rpc` into an API Tree. -RPC Responder는 `server/rpc`아래 모든 명령들을 API 트리로 로드 합니다. +The RPC responder loads all commands in `server/rpc` into an API Tree. Thus the command to call 'products.latest' will be matched to the 'latest' function in the 'products' file `/server/rpc/products.js`. - Thus the command to call 'products.latest' will be matched to the 'latest' function in the 'products' file `/server/rpc/products.js`. -그래서 그명령어는 `/server/rpc/products.js`.파일에서 'products' 안에 'latest'와 일치 되는 'products.latest'를 호출 할 것입니다. +RPC Responder는 `server/rpc`아래 모든 명령들을 API Tree로 로드 합니다. 그러므로 그 명령어는 `/server/rpc/products.js`파일의 'products' 안에 'latest'와 매치되어질 함수 'products.latest'를 호출 할 것입니다. The `products.js` file should contain the available actions as so: -`products.js` 파일은 이처럼 적당한 action들을 포함해야 함. +`products.js` 파일은 이처럼 적당한 action들을 포함해야 함: ``` javascript // server/rpc/products.js @@ -51,13 +43,10 @@ exports.actions = function(req, res, ss){ ``` ### Sending Arguments -### 매개변수 전달 +### 인자 전달 -The RPC Responder can take and pass unlimited arguments intuitively. -RPC Responder 는 무제한의 인자를 지관적으로 얻거나 전달 할 수 있습니다. - -For example let's write another action on the server: -예로 서버에 또 다른 액션을 작성하자: +The RPC Responder can take and pass unlimited arguments intuitively. For example let's write another action on the server: +RPC Responder는 무제한의 인자를 직관적으로 취하거나 전달 할 수 있습니다. 예를들어 서버에 또 다른 액션을 작성 하자: ``` javascript // server/rpc/products.js @@ -79,7 +68,7 @@ exports.actions = function(req, res, ss){ ``` To call this from the browser we'd use: -이것을 우리가 사용하는 브러우저에서 호출: +이것을 사용하고 싶은 브러우저에서 호출: ``` javascript // client/code/main/products.js @@ -92,16 +81,13 @@ ss.rpc('products.topSelling', '2012-01-01', '2012-01-31', productType, function( ``` You may pass as many arguments as you want - just remember the last argument should always be the callback if you're expecting a response from the server. -당신이 원하는 만큼 많이 전달 할수 있습니다. - 단 서버로부터 응답을 기대한다면 마지막 인자는 항상 콜백(함수)라는 것을기억하세요. +당신이 원하는 만큼 많은 인자들을 전달 할수 있습니다. - 단 서버로부터 응답을 기대한다면 마지막 인자는 항상 콜백(함수)가 되어한다는 것을 기억하세요. ### How does it work under the hood? ### 그것은 내부에서 어떻게 동작하는 것일까요? -The RPC Responder serializes messages in both directions using JSON. -RPC Responder는 JSON을 이용하여 쌍방향으로 메세지들을 직렬화 합니다. - -Thus the actual message sent over the wire is a string which looks like this: -그래서 실제로 보내지 선을 넘어로(네트워크를 넘어로)보내지는 내용은 이런식의 문자열입니다: +The RPC Responder serializes messages in both directions using JSON. Thus the actual message sent over the wire is a string which looks like this: +RPC Responder는 JSON을 이용하여 쌍방향으로 메세지들을 직렬화 합니다. 그러므로 실제로 보내지 선을 넘어로(네트워크를 넘어로)보내지는 내용은 이런식의 문자열입니다: {id: 1, m: 'method.to.call', p: [param1, param2, ...]} From e89c31e9865db17aac3d88091348315bcc7c494a Mon Sep 17 00:00:00 2001 From: codercay Date: Tue, 29 May 2012 08:43:42 +0900 Subject: [PATCH 2/4] tran http_middleware.md into ko, need to check out. --- doc/guide/ko/http_middleware.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/doc/guide/ko/http_middleware.md b/doc/guide/ko/http_middleware.md index 57d95052..163a7993 100644 --- a/doc/guide/ko/http_middleware.md +++ b/doc/guide/ko/http_middleware.md @@ -1,21 +1,29 @@ # HTTP Middleware #### Warning: Incomplete. More to follow +#### 경고: 미완료. 더 수행해야 함. -SocketStream provides a stack of Connect HTTP middleware which is used internally to serve single-page clients, asset files and static files (e.g. images) in `client/static`. +SocketStream provides a stack of Connect HTTP middleware which is used internally to serve single-page clients, asset files and static files (e.g. images) in `client/static`. +SocketStream 은 싱글-페이지 클라이언트에게 `client/static` 안에 asset 파일들 과 static 파일 (예 이미지들) 서비스하기 위한 내부적으로 사용되는 Connect HTTP 미들웨어 스택을 제공합니다. -The Connect `app` instance is accessible directly via the `ss.http.middleware` variable within `app.js`. +The Connect `app` instance is accessible directly via the `ss.http.middleware` variable within `app.js`. +그 Connect `app` 인스턴스는 `app.js`안에 `ss.http.middleware`변수를 통해 직접적으로 접근하는 것이 가능합니다. -SocketStream allows you to prepend new middleware to the top of the stack (to be processed BEFORE SocketStream middleware) using: +SocketStream allows you +to prepend new middleware to the top of the stack (to be processed BEFORE SocketStream middleware) using: +SocketStream는 새로운 middleware가 스택의 꼭대기에 첨부 될수 있는 (SocketStream middleware 전에 처리하는) 사용을 허용한다: ss.http.middleware.prepend() For example you could add: +예를 들어 추가 할 수 있음: ss.http.middleware.prepend( ss.http.connect.bodyParser() ); -Because SocketStream adds `connect.cookieParser()` and `connect.session()` to the stack, if the middleware you're wanting to use requires sessions support (i.e. access to `req.session`) it will need to be appended to the bottom of the stack AFTER SocketStream middleware has been loaded as so: +Because SocketStream adds `connect.cookieParser()` and `connect.session()` to the stack, if the middleware you're wanting to use requires sessions support (i.e. access to `req.session`) it will need to be appended to the bottom of the stack AFTER SocketStream middleware has been loaded as so: +만약 당신이 사용하고자 하는 미들웨어가 세션들의 지원을 요청하는 경우(즉, `req.session`로 접근), 왜냐하면 SocketStream은 `connect.cookieParser()` 과 `connect.session()`을 스택에 추가하기 때문에 로드된 SocketStream 미들웨어 후에 스택의 바닥에 삽입해야 할 것이다. ss.http.middleware.append( everyauth.middleware() ); -Apart from determining where the middleware should be added, the `prepend()` and `append()` functions work in exactly the same way as `connect.use()`. \ No newline at end of file +Apart from determining where the middleware should be added, the `prepend()` and `append()` functions work in exactly the same way as `connect.use()`. +미들웨어와 추가해야 하는 곳의 결정과는 별개로, `prepend()`과 `append()`함수 들은 정확히 `connect.use()` 와 같은 방법으로 동작합니다. From 46c2c51629076cec0ac5140fbc17f6f97d2ddddc Mon Sep 17 00:00:00 2001 From: codercay Date: Tue, 29 May 2012 15:32:44 +0900 Subject: [PATCH 3/4] tran pub sub event into ko --- doc/guide/ko/pub_sub_events.md | 159 +++++++++++++++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 doc/guide/ko/pub_sub_events.md diff --git a/doc/guide/ko/pub_sub_events.md b/doc/guide/ko/pub_sub_events.md new file mode 100644 index 00000000..6c0767a0 --- /dev/null +++ b/doc/guide/ko/pub_sub_events.md @@ -0,0 +1,159 @@ +# Pub/Sub Events + +SocketStream includes an powerful pub/sub system allowing you to easily send messages to connected browsers over the websocket. +SocketStream 은 연결된 웹브라우저에게 웹소켓으로 쉽게 메세지를 전송 할 수 있는 강력한 pub/sub시스템을 가지고 있습니다. + +### 1. Sending to Everyone +### 1. 모두에게 보내기 + +To send an event to every connected client (for example to let them know the server's going down for maintenance), use the `ss.publish.all` method: +연결된 모든 브라우저에게 이벤트를 보내기 위해(예를 들어 서버가 유지보수를 위해 다운시켜야 함을 알리기 위해), `ss.publish.all`를 사용 함: + +``` javascript +// in a /server/rpc file +ss.publish.all('flash', 'Notice: This service is going down in 10 minutes'); +``` + + +Receive the event in the browser with: +브라우저에서 이벤트 받기: + +``` javascript +// in a /client/code file +ss.event.on('flash', function(message){ + alert(message); +}); +``` + +Note: The first argument specifies the event name. All subsequent arguments will be passed through to the event handler. +노트: 첫번째 인자는 이벤트 이름으로 지정한다. 뒤이은 모든 인자들은 이벤트 핸들러에게 전달 되어질 것이다. + + +### 2. Sending to Private Channels +### 2. 프라이빗 채널로 전송하기 + +Sometimes you'll want to send events to a subset of connected clients. For example, you may have a chat app with multiple rooms. +가끔 접속된 일부 클라이언트에게만 이벤트를 전송하고 싶을 것입니다. 예를 들어, 여러개의 방에서 채팅하는 앱 + +Each client session can be subscribed to an unlimited number of private channels using the following commands: +다음에 명령을 사용하여 각각의 클라이언트 세션은 무제한으로 프라이빗 채널이 구독될 수 있습니다.(열려 질수 있습니다. 참조될 수 있습니다.) + +``` javascript +// in a /server/rpc file after calling req.use('session') middleware + +req.session.channel.subscribe('disney') // note: multiple channel names can be passed as an array + +req.session.channel.unsubscribe('kids') // note: multiple channel names can be passed as an array + +req.session.channel.reset() // unsubscribes the session from every channel + +req.session.channel.list() // shows which channels the session is currently subscribed to +``` + + + +Sending a message to a private channel is similar to broadcasting to all; however, note the first argument now specifies the channel name (or channels if you pass an array): +프라이빗 채널로 메세지를 전송 하는 것은 모두에게 브로드캐스팅(전송)하는 것과 비슷함; 하지만, 첫번째 인자에 채널(또는 채널들 채널 배열로 기록)이름을 기록 함: + +``` javascript +// in a /server/rpc file +ss.publish.channel('disney', 'chatMessage', {from: 'jerry', message: 'Has anyone seen Tom?'}); +``` + +Receive these events in the browser in the usual way. Note: If the event was sent to a channel, the channel name is passed as the final argument to the event handler: +이일반 적인 방법으로 브라우저에서 이러한 이벤트를 받음. 노트: 채널로 이벤트가 보내진다면, 채널이름은 마지막 인자로 이벤트 핸들러에 전달 됨 : + + +``` javascript +// in a /client/code file +ss.event.on('chatMessage', function(msg, channelName){ + console.log('The following message was sent to the ' + channelName + ' channel:', msg); +}); +``` + + +### 3. Sending to Users +### 3. 사용자들에게 보내기 + +Once a user has been [authenticated](https://github.com/socketstream/socketstream/blob/master/doc/guide/en/authentication.md) (which basically means their session now includes a value for `req.session.userId`), you can message the user directly by passing the `userId` (or an array of IDs) to the first argument of `ss.publish.user` as so: +한번이라도 인증이 되어지면(기본적으로 사용자의 현재 세션은 `req.session.userId`의 값을 포함 하는 것을 의미 함), `ss.publish.user`의 첫번째 인자에 `userId`(또는 ID들의 배열)을 (삽입하여) 사용자에게 직접 메세지를 보낼 수 있습니다. + + +``` javascript +// in a /server/rpc file +ss.publish.user('fred', 'specialOffer', 'Here is a special offer just for you!'); +``` + + + +### 4. Sending to Individual Clients (browser tabs) +### 4. 개체 각각의 클라이언트에게 전송하기 (브라우저 탭들) + +If a user opens multiple tabs in the browser, each will share the same `req.session.id` and private channel subscriptions (as channels are attached to sessions). +만약 사용자가 브라우저로 복수의 탭을 열은 경우, 각각은 `req.session.id` 과 프라이빗 채널 구독(참조) 를 공유합니다.(채널들이 세션에 첨부된 되어 있으므로) + + +Normally this is the desired behavior, but in rare cases you'll want to message a particular client (i.e. a individual browser tab): +일반적으로 이것은 올바른 동작이지만, 드문 경우지만 개개의 클라이언트에게 메세지를 보내길 원할 수 있습니다. (예 각각의 브라우저 탭): + + +``` javascript +// in a /server/rpc file +ss.publish.socketId('254987654324567', 'justForMe', 'Just for one tab'); +``` + + +You can find the socketId by calling `req.socketId` in your server-side code. Note, this attribute may not always be present (e.g. if you invoke the RPC method via `ss-console`), so plan accordingly. +당신은 서버측 코드에서 `req.socketId` 호출 하여 socketId를 찾을 수 있습니다. 노트: 이 속성은 항상 존재하지 않을 수 있으므로 적절히 계획하시오.(예: `ss-console`으로 RPC메소드 호출) + +Please be aware that `req.socketId` will change if you refresh the page, so it's much better to assign clients to private channels and use those wherever possible. +페이지가 새로고침 되면 `req.socketId`는 변경될 걸 이라는 걸 인식했으면 하며, 그래서 가능한 모든때에 클라이언트들에게 프라이빗 채널들을 할당하고 그것울 이 용하는 것이 훨씬 낫다. + + +### Publishing Events via app.js +### app.js를 통해 이벤트 발행하기 + +Sometimes you'll want to publish events from outside your `/server/rpc` files, such as your `app.js` file. The entire `ss` API available to actions in `/server/rpc` is also available in `app.js` via the `ss.api` object. Hence to publish an event to `all` you would call: +떄떄로 `app.js`처럼 /server/rpc`파일 외부에서 이벤트들을 발생하길 원할 수 있을 것이다. /server/rpc`에서 action들에 사용할 수 있는 전체의 `ss` API는 `ss.api`의 객체를 통해 `app.js`에서 또한 이용 할 수 있다. 따라서 모두에게 이벤트를 게시하기 위해 당신은 호출 해야 함: + +``` javascript +// in /app.js +ss.api.publish.all() +``` + + +### Event Transports +### 이벤트 수송 + + +By default SocketStream sends all published events over an internal event emitter. This works fine during development and under moderate load, however; once your app outgrows a single process, you'll need to switch to an external event transport to allow you to run multiple SocketStream processes/servers at once. +모든 게시된 이벤트들은 내부의 이벤트 emitter(게시자)를 통해 기본적인 SocketStream으로 보내집니다. 이것은 개발단계 와 약간의 부하에서도 잘 동작하지만; 일단 당신의 앱이 싱글 프로세스를 벗어나게 되면, 당신은 한번에 여러 프로세스들/서버들이 한번에 실행할 수 있도록 외부의 이벤트를 수송하도록 전환할 필요가 있을 것입니다. + +Event transports are implemented in a modular way, so it's possible to write a simple driver to support any Message Queue. +이벤트 수송은 모듈방식으로 구현될 수 있어서 어떤 메세지 큐를든지 지원 할 수 있는 간단한 드라이버 형태로 작성될 수 있습니다. + +To use the in-built Redis transport (recommended), add the following line to your `app.js` file: +(추천하는)내장된 Redis 수송을 사용하기 위해, 다음 라인을 당신의 `app.js`추가: + +``` javascript +// in app.js +ss.publish.transport.use('redis'); // any config can be passed to the second argument +``` + + +Using an external event transport has an important added benefit: Now you can easily push events to connected browser from external (non Node.js) systems. Simply connect the external system (e.g. an Erlang service) to the same instance of Redis and publish messages using the same JSON message format. +외부 이벤트 수송을 이용하면 중요한 잇점이 있습니다: 지금 외부 시스템(Node.js는 아니고)으로부터 연결된 브라우저에게 쉽게 이벤트를 보낼수 있습니다. JSON 메세지 포멧을 이용하여 외부 시스템과 같은 인스턴스, 게시한 메세지를 간단히 연결한다.(예 Erlang 서비스) + + +**Notes** +**노트** + +1. If the channel name you specify does not exist it will be automatically created. Channel names can be any valid JavaScript object key. If the client gets disconnected and re-connects to another server instance they will automatically be re-subscribed to the same channels, providing they retain the same `sessionId`. Be sure to catch for any errors when using these commands. +1. 지정한 채널이름이 존재하지 않는 경우 자동으로 생성되 것입니다. 채널 이름들은 유효한 JavaScript 객채 키가 될 수 있습니다. 접속이 끈긴 클라이언트가 다른 서버 인스턴스로 재 접속을 하는 경우 그것들이 가지고 있는 같은`sessionId`가 제공하기 때문에 그것들은 자동적으로 같은 채널들로 재-구독(재-참조) 될 것입니다. + +2. The SocketStream Pub/Sub system has been designed from the ground up with horizontal scalability and high-throughput in mind. The `all` and `channel` commands will be automatically load-balanced across all SocketStream servers when an external event transport is used. +2. SocketStream Pub/Sub시스템음 수평 확장성 과 높은 처리량을 염두해 두고 하위에서 상향으로 설계되었습니다. `all`과 `channel`명령어들은 외부의 이벤트 수송이 사용되어 질 때 자동적으로 모든 SocketStream 서버들 간의 로드-밸런싱(균형-조정)될 것입니다. + +3. It is important to remember messages are never stored or logged. This means if a client/user is offline the message will be lost rather than queued. Hence, if you're implementing a real time chat app we recommend storing messages in a database (or messaging server) before publishing them. + +3. 그것은 로그를 남기거나 메세지를 저장하지 않는 것을 기억하는 점이 중요합니다. 이것은 클라리언트/사용자가 오프라인에 되면 메세지를 싫어 버리기 보다는 오히려 큐에 적제된 상태를 의미합니다. 그러므로 실시간 채팅앱을 구현하는 경우 메세지를 게시하기 전에 데이터베이스에(또는 메세징 서버에) 저장하는 것을 추천합니다. \ No newline at end of file From 33a3bafd5816cc2a5fd82a87829163907132da68 Mon Sep 17 00:00:00 2001 From: codercay Date: Tue, 12 Jun 2012 16:30:43 +0900 Subject: [PATCH 4/4] loading_assets_on_demend change encode --- doc/guide/ko/loading_assets_on_demand.md | 30 ++--- doc/guide/ko/writing_request_responders.md | 131 +++++++++++++++++++++ 2 files changed, 146 insertions(+), 15 deletions(-) create mode 100644 doc/guide/ko/writing_request_responders.md diff --git a/doc/guide/ko/loading_assets_on_demand.md b/doc/guide/ko/loading_assets_on_demand.md index 51704aac..cd70a4f2 100644 --- a/doc/guide/ko/loading_assets_on_demand.md +++ b/doc/guide/ko/loading_assets_on_demand.md @@ -1,37 +1,37 @@ - -# ʿҶ Assets ҷ + +# 필요할때만 Assets을 불러오기 - ִ ۴ٸ, κ dzʶپ ˴ϴ. ֳϸ ϸ, Ŭ̾Ʈ Ͽٰ Ƴ, Դϴ. +만들고 있는 앱이 작다면, 이 부분은 건너뛰어도 됩니다. 왜냐하면 가능하면, 클라이언트의 에셋 한 파일에다가 모아놓고, 한 번에 모두 보내는 편이 낫기 때문입니다. -׷ ִ ũų, Ǵ 쿡 ? iCloud.com ó. +그러나 만들고 있는 앱이 크거나, 서로 구별되는 여러 개의 섹션을 가지는 경우에는 어떨까요? 예를 들면 iCloud.com의 경우처럼요. -ϽƮ û 񵿱 ڵ带 ۿٰ ε ֽϴ. ߿ ٸ µ ̷ Դϴ. +소켓스트림에서는 요청이 있을 때마다 비동기적인 방식으로 코드를 앱에다가 로드할 수 있습니다. 나중에는 다른 에셋도 이렇게 할 수 있을 것입니다. -### ڵ带 εϱ +### 코드를 로드하기 -ŸԵ, εǾ `require()` ϴ. `require` Լ κ ϴ. +안타깝게도, 로드되어 있지 않은 모듈을 직접 `require()`할 수는 없습니다. `require` 함수는 서버로부터 모듈을 가져올 때까지 브라우저는 멈춥니다. - ϽƮ `ss.load.code()` ɾ ؼ, 񵿱 ߰ ڵ ε ֽϴ. ϴ ûϽ ڵ尡 εǸ, ϽƮ ݹ մϴ. ׷ Ư ʾƵ, `require()` ؼ ο ε ֽϴ. +하지만 소켓스트림에서는 `ss.load.code()` 명령어를 사용해서, 비동기적으로 서버에서 추가적인 코드 모듈을 로드할 수 있습니다. 일단 여러분이 요청하신 코드가 다 로드되면, 소켓스트림에서는 콜백을 수행합니다. 그래서 특별한 구문을 쓰지 않아도, `require()`를 사용해서 새로운 모듈을 로드할 수 있습니다. - غ. ø̼ ⿡ ο `/client/code` 弼. ׸ ο `/client/code/mail`̶ ̸ ̼. ȿ `search.js` ִٰ ϰڽϴ. +직접 해보세요. 어플리케이션 모듈에 사용할 새로운 폴더를 `/client/code` 하위에 만드세요. 그리고 새로운 폴더에 `/client/code/mail`이라고 이름을 붙이세요. 이 폴더 안에는 `search.js`라는 모듈이 있다고 가정하겠습니다. ```javascript -//Ŭ̾Ʈ +//클라이언트쪽의 모듈 ss.load.code('/mail', function(){ - // /client/code/mail ȿ ִ εǾϴ. - // Ʈ ӽ̽ (/)(??) û ֽϴ. + // /client/code/mail 안에 들어있는 모듈이 모두 로드되었습니다. + // 루트의 네임스페이스인 (/)(??)는 보통의 방법으로 요청할 수 있습니다. var search = require('/search'); @@ -45,11 +45,11 @@ ss.load.code('/mail', function(){ -ϼ: εϴ , ȿ ִ ׻ Ʈ (/) ȿ ε Դϴ. ο ٸ ӽ̽ ȿ ƮϽ÷ εϽ÷ ϳ ų, εϴ ȿ ϳ 弼. +주의하세요: 여러분이 로드하는 폴더와 상관없이, 폴더 안에 있는 모듈은 별도의 설정이 없으면 항상 루트 (/) 안에 로드될 것입니다. 새로운 모듈을 다른 네임스페이스 안에 마운트하시려면 로드하시려는 폴더를 하나 만들거나, 로드하는 폴더 안에 하위 폴더를 하나 만드세요. -### ڵ ij +### 자동 캐싱 - κ ɴϴ. Ŀ ̷ û ʰ ٷ ȯ˴ϴ. +모듈은 서버로부터 한 번만 가져옵니다. 동일한 폴더에 대해 그 이후에 이루어지는 요청은 서버와 접속하지 않고 바로 반환됩니다. diff --git a/doc/guide/ko/writing_request_responders.md b/doc/guide/ko/writing_request_responders.md new file mode 100644 index 00000000..a352cdc8 --- /dev/null +++ b/doc/guide/ko/writing_request_responders.md @@ -0,0 +1,131 @@ +# Writing your own Request Responder +# 나만의 Request Responder 작성하기 + +Note: This documentation is aimed at developers who are comfortable creating Node.js modules and wish to extend the core functionally of SocketStream. + +노트: 이 문서는 편리한 Node.js 모듈의 생성 과 SocketStram의 코어를 기능적으로 확장 하기를 희망하는 개발자들을 대상으로 합니다. + +### Introduction +### 소개 + +SocketStream is bundled with two Request Responder modules by default: `rpc` and `events`. +SocketStream은 기본적으로 두 Request Responder를 제공합니다: `rpc` 와 `events`. + +For many applications these two responders maybe all you need; however, SocketStream gives you the flexibility to write your own responder as an external module. +많은 어플리케이션의 경우 이 두 Responder들은 당신이 필요로하는 모든 것일지 모릅니다. 하지만 SocketStream은 외부의 모듈 처럼 당신의 Responder를 작성 할 수 있는 유연함을 제공합니다. + +You may wish to write your own responder to: +이러한 Responder를 작성하고 싶을 수 있음: + +* Experiment with new ways to access model data from the browser (e.g. implement a MongoDB-esq client-side API) +* 브라우저로 부터 새로운 방법으로 모델 데이터를 접근 하는 실험( 예 implement a MongoDB-esq client-side API) + +* Investigate the best way to implement model synching to a persistent store (for Backbone.js, Ember.js, or others) +* (Backbone.js, Ember.js, or others에 대한)영속적인 store 와 동기화 하는 모델 구현을 위한 최고의 방법 조사 + +* Develop an ultra low-bandwidth custom protocol for high-speed action gaming (no need to use JSON) +* (JSON을 이용할 필요가 없는)하이스피드 액션 게임을 위한 극단적으로 낮은 대역폭의 맞춤 프로토콜 개발 + +* Make the client send a regular heartbeat to the server (to obtain presence info or calculate users online) +* 규칙적인 (정기적인 데이터)맥박??을 서버로 전송하는 클라이언트 만들기(현재 정보를 얻기 위해 또는 온라인 상태의 사용자를 계산하기 위해) + +* Log browser clicks, mouse movements, errors encountered, etc and send the data to the server in the most efficient way +* 브라우저 클릭, 마우스 이동, 발생한 에러들을 로깅하고 가장 효과적인 방법으로 서버에 데이터를 전송하는 방법 + +* Explore streaming pub/sub event streams, 'ZeroMQ in the browser', or any other experimental concepts +* pub/sub event 스트림이 스트림 되는 것을 조사,'브라우저에서 ZeroMQ' , 또는 어떤 다른 실험적인 개념들 + +We will feature the best third-party Request Responders on our website, www.socketstream.org, in the near future. +가까운 미래에 우리의 웹사이트, www.socketstream.org,에서 Request Responder 특징을 나타낼 것이다. + +### What exactly is a Request Responder? + + +A Request Responder is basically a message handler. + +Think of the websocket as a pipe with many different types of messages continually flowing in both directions. Each Request Responder module used by SocketStream is assigned a unique ID (the `responderId`) which is automatically prepended to each incoming and outgoing message. + +For example, assuming the `rpc` responder was the first to be loaded (and hence assigned an ID of 1), a typical incoming message destined for this responder would look something like this: + + 1|{id: 1, m: 'method.to.call', p: [param1, param2, ...]} + +Note the `responderId` is sent before the pipe (`|`) character. + + +### Getting Started + +Request Responders are simply regular Node.js modules which you can easily create and publish on NPM. To help you get started quickly, we've made an ultra-simple example called `echo` which you can clone from Github and extend as you wish: + + git clone https://github.com/socketstream/ss-echo-responder.git + + +### Adding a new responder to your app + +Request Responders are added to your application stack by passing a module to SocketStream, as so: + +```javascript +// in /app.js +ss.responders.add(require('ss-echo-responder')); +``` + +Any optional config can be passed directly to the responder by passing an object as the second argument. + + +### Message Serialization + +Each Request Responder sends and receives messages as a `string`; giving you, the developer, complete control over the message length and format. + +For complex messages (involving objects) you'll probably want to serialize each message using JSON, as we do with the `rpc` responder. However, if you're just sending basic numeric data (e.g. an ID + X/Y coordinate for a character moving around a virtual world), sending a few groups of digits separated by commas will result in fewer bytes over the wire and no JSON overhead. + +Note: Even if you choose not to use JSON, if you were to packet-sniff the websocket connection, you'll notice Socket.IO still uses JSON as part of it's own internal message protocol. In the future SocketStream will support additional Websocket Transports allowing you to pick and choose the best combination of transports and responders for your particular use case. + + +### Sending Code to the Client + +The Request Responder API allows your module to send client-side JS libraries (e.g. `backbone.js`), custom modules, and arbitrary JavaScript code to the browser before any application code is sent. + +SocketStream automatically handles the packing/minification of any client-side code when the end user runs the app in `production` mode, but please be **very** conscious that every byte of client-side code you send will increase the load time of the app. + + +### Registering a Client API + +Should you wish to register a function on the main `ss` object (in the same way we do with `ss.rpc()`), you may call `ss.registerApi()` in your client-side code (see the `ss-echo-responder` for an example). How you choose to implement the client-side API is left entirely up to you. + +For example, the `rpc` responder allows you to call `ss.rpc('my.function.name', param1, param2, ...)` which takes an unlimited number of incoming arguments and transforms them into a JSON-serialized message. + +You may view the source code of the `rpc` responder here: https://github.com/socketstream/socketstream/blob/master/src/request/responders/rpc + + +### Request Middleware + +Request Middleware defined in `/server/middleware` is passed through to all Request Responders and is available for use if you desire. + + +### RPC-style Callbacks + +Request Responders simply allow you to pass messages (as strings) from the client to the server, and vice versa. + +Implementing non-blocking bi-directional async message responders is possible (and relatively simple) by appending an sequential ID to each outgoing message and implementing a simple callback stack. This is exactly what we do with the built-in `rpc` responder. Take a look at the annotated source code here for inspiration: + +https://github.com/socketstream/socketstream/blob/master/src/request/responders/rpc/client.coffee + + +### Namespacing Server-side Files + +If your Responder allow users to create server-side files, for example to define schema for models, put them in `/server/name_of_your_responder`. + +We recommend you use the `apitree` NPM module for namespacing (as we do with the `rpc` responder), but the ultimate choice is left up to you - the developer. + + +### API Status + +The 'websocket' interface should now be stable. We're currently working on finalizing additional interfaces to allow your responder to be called over the REPL (using `ss-console`), as part of a server-side test suite, or even over HTTP requests. + +Additional interfaces will be documented shortly once they are stable - however you are not obliged to add them to your responder. + +We welcome feedback from developers and will use this to improve the API design in future releases. We will do our best to ensure any changes do not break the existing API, but getting this right for the long-term is of primary importance. + + +### Support available! + +Please do not hesitate to get in touch if you need help at any stage of the process. Please log a Github issue or find us on IRC. \ No newline at end of file