xat-server 0.1.0 candidate

[huumanoid]

Introduction

This pull request introduces a bunch of features which may lead xat-server to becase 0.1.0, according to issue list. Let's discuss all this stuff.

Changes

• Pools
• Ranks
• Compilation
• Packet builders

  Thanks

Thanks @iiegor for his feedback, i was glad to see you are interested in my collaboration.

1. Pools

Behavior

When user joins pool, it appears online only for users with same pool. When user changes pool from 0 to 1, users in 0 receive <l>, users in 1 receive <u>. User sends messages only for users with same pool. User receives messages only from users with same pool.

Implementation

new method changePool added to chat. This method emit <l>, changes client's onPool and performs joinRoom. Later, while implementing banpool, we should use changePool to put user to banpool. While implementing rankpool, we should add checks to changePool.

Pools tests are into test/pools.coffee.

Issues

Currently, database scheme for chats table doesn't contains onPool field, but it seems that onPool lies into pool field. As for now, it's ok.

TODO

• Rankpools
• Dynamic pools

  Dynamic pools

Original xat server creates additional pools when amount of online users exceed 50, and connects new users to random additional pools.

2. Ranks

Ranks handling added:

• Mainowner's pass, passed by <j2 r="pass"... /> is handled.
• Permanent rank making implemented (no gconfig)

  Behavior

When moderator changes user's rank:

• user receives <c>, if user is on chat.
• everyone in same pool receives <m t="/m" p="STR_RANK" .. />.
• user receives <i> and <gp>, if user is on chat (chat packet builder for <i> and <gp> introduced).
• others receives <u> with actual user's rank, if user is on chat.

Restrictions:

• User can't change rank of someone who has greater than or equal rank to user's one.
• Members and guests can't change ranks.
• User only can make lower ranks than it has.

  Implementation

Ranks stored in ranks table of db, ranks are fetched in chat.joinChat, making handled by chat.makeUser method. Current code assume that only rank data stored in ranks.f. It means, if we want to add more significant bits to ranks.f, we should change at least this line. Rank data structure added to src/structures/rank.coffee. Implements rank conversions from/to string/number, rank comparison.

Discuss

• Have I understood ranks.f right? Some insertions into ranks in sql script contains strange values of f (eg 5).
• client.user.f and client.chat.rank are dependent fields, but they are parts of plain objects. Probably, we should implement class that would contain some logic based on f complex nature.
• What is Commander? Is it a tool for chat administrator or server administrator? In first case, we only need to add rank checking to solve #7.

  TODO

• add temp ranks.
• for offline targets, only allow to make them guests, restrict for other ranks.

  3. Compilation

Compilation task added to package.json.

npm run compile

Output folder is lib. Binary that runs compiled server: bin/xat-production To run compiled server, execute:

npm run start-production

Tests uses compiled version of chat. To switch to coffee version instead, change symlink bin/xat-test, which points to server's binary used to tests.

4. Packet builders

Most of this section content copied from #45 Also, packet builders for chat added.

I've investigated for packet creation methods, which have duplications. I've found, that creation of 'u' packets and 'm' packets for main chat messages are duplicated. packet-builders/user and packet-builders/message have been created and hardcoded packet composings have been replaced. I think this stuff will evolve as project grows. Some refactoring needed. For example: may be we should impelement separate method for expanding of 'response-to-locate' packet. May be not.

Discuss

We should implement separate methods for online and offline users.

At first sight, it's convenient to create buildUser method, which can recognize, is user online or not, and make fetch user from db in the second case. However, it requires buildUser to be async. Returning promise from buildUser or even using callback may seems fine, but check out this lines. Here, buildUser should be called in cycle. Making an array of promises and passing them to Promise.all or making recursive calls of callbacks is not the case. That's why sync version of buildUser() have been created. I think, we can implement unified buildUser method even if there is C# async/await syntax in coffee-script (see ES7 async/await for coffeescript)

5. Other

@houndci-bot "@ must not be used stand alone"

I propose to ignore this warn. According to coffee-lint docs and coffee-script discussion about standalone @ and this, it's not recommended to use neither standalone @ nor this. But we need to.