On 01/09/05 19:12:44, Gary Kramlich wrote:
> We need a better way to handle the info command. The way we're
> handling
> it now is um, fugly at best. I have a couple thoughts on the matter,
> but I'm interested in what you guys think we should do.
>=20
> For starters a giant if block, isn't very ideal. Also we're going to
> end up with a ton of duplicate code.
>=20
> One of the ideas I had was to move it to a stack based system. Where
> by we keep track of what commands we've sent that should be getting =20
> info commands. That also has problems though like when we sign on =20
> and get our buddy list, which spews out an info message for each =20
> buddy.
The fact is that it isn't so simple :/
As an example, friends list isn't termined... I mean there's no way to =20
know we received all our friends, cause it simply list them without =20
ending with something recognisable. How to know when to stop to =20
expecting them?
Uhm, now I found an idea :)
Maybe we can do somthing like that:
/f l
/foo
Then the output will be:
(INFO) Your friends are:
(INFO) 1: ***
(INFO) 2: ***
...
(INFO) n: ***
(ERROR) That is not a valid command. Type /help or /? for more info.
And we get the end of the list :)
Anyway it's just a workaround... maybe there are other example of this =20
protocol stupidity?
> My other idea is to setup some sort of rules system that will be a
> static array that we can just iterate through for each info message.
> This could be a little bit of a performance hit (although I doubt =20
> it), but if it makes the code cleaner, I'm all for it.
Yes but the output format of INFO depends... we can't simply compare it =20
to the elements of a static array...
For example from a "/where foo" command we get something like:
(INFO) foo is using Chat, in Public Chat 1 bla bla bla
"foo" is the first token :)
We would code a sort of dynamic check anyway...
I'm for the second idea anyway... I think is the easier and functional.
cya
|
