1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
|
[Sorry, this file is in french]
Voici la structure du bobot++ (en gros).
L'objet principal, qui encapsule tout, est l'objet Bot. Il se charge
de grer la connection au serveur, et de rcuprer le texte qu'il
trouve sur les sockets (serveur IRC et DCC Chat).
Il contient une instance de :
- ChannelList : objet listant les channels sur lesquels on est
- UserList : liste des utilisateurs enregistrs
- ShitList : liste des shits (dingue, a)
- ServerList : liste des serveurs
- TodoList : liste des commandes envoyer un instant donn. Sert
pour le tban et tkban.
- userFunctions : liste des fonctions fournies l'utilisateur
- wantedChannels : les Channels sur lesquels on veut tre
- ignoredUserhosts : les userhosts ignors (avec le temps pendant
lequel on les ignore)
- spyList : liste des nick des personnes qui espionnent les messages
envoys au bot
- serverConnection : objet charg de grer la connexion au serveur
- dccConnections : liste des connexions DCC Chat
- userhostMap : objet interne servant grer les requetes USERHOST
de manire asynchrone (la mthode utilise est
rigolote).
L'objet ChannelList contient une map de channels (map qui fait
correspondre un objet Channel un nom de channel).
L'objet Channel :
- divers champs pour tracer les modes en vigueur, la clef, etc...
- channelMemory : association {nick => User} pour toutes les
personnes sur le channel
- channelBanlist : liste des {mask,time} pour les personnes bannies
L'objet channel parse galement les MODEs qui le concernent.
L'objet ServerConnection, qui hrite de l'objet Connection, se charge
de grer les communications avec le serveur IRC. La mthode
handleInput() distribue les commandes l'objet Parser. Il contient
une instance de ServerQueue, objet destin envoyer les commandes au
serveur (et qui au passage bufferise ces envois, et qui terme
devrait regrouper les commandes quand il le peut).
La classe Parser se charge de parser les commandes envoyes par le
serveur. S'il s'agit d'un message, et que ce message dbute par le
caractre de commande, on fait appel aux mthodes de la classe
UserCommands, qui se chargent d'effectuer les commandes appropries.
La classe Person (je ne sais pas si ce mot existe en anglais :-) est
utile pour envoyer des messages l'auteur d'une commande. Comme les
mthodes de la classe UserCommands peuvent tre appeles depuis une
commande envoye sur le serveur ou depuis une commande reue par DCC
Chat, il faut pouvoir rpondre par le moyen adquat. La classe Person
ajoute une couche d'abstraction pour que l'on n'ait pas se soucier
de la mthode pour envoyer le message.
EVOLUTIONS:
===========
Pour l'ajout des scripts, il va falloir faire une classe Interp (qui
existe dj moiti). Il faut sparer la classe UserCommands en deux
couches. Une premire couche qui se chargera de parser les arguments,
et une deuxime couche qui effectuera les commandes. Le point dlicat
est la gestion des erreurs. On pourrait peut tre crer une classe
spciale Message pour retourner des messages d'erreur et/ou des
codes. A voir.
Un des principaux problmes auquel on va se heurter est le fait que
Guile n'a pas l'air d'tre rentrant, ni thread safe. Or le bot est
conu pour tre multithread (un jour :-). Il faudra donc crer un
objet statique Interp, et lui passer l'adresse de l'objet Bot qui
l'appelle en argument toutes les fonctions.
Il va falloir ajouter des hooks (l'quivalent des /on avec ircII) et
des actions prprogrammes.
|
