Not enough clear state/rule management for extensions

[eazar001]

Things like number of requests as well as timeouts are examples of attributes that should be handled per request. Simple assertion of dynamic facts perhaps referenced via gen_sym/2 could help with this endeavor. Consider a design for this.

[Anniepoo]

A reflection interface would also be convenient - something that lets one enumerate all known/loaded extensions

[eazar001]

Anniepoo suggests:
Maybe extensions need to register a reserved word :- yesbot_command(emote, emoticon)

Reserved keywords for extensions is also a legitimate point for state management of yesbot overall.

[eazar001]

A reflection interface would also be convenient - something that lets one enumerate all known/loaded extensions
-Anniepoo

I have started something like this in the form of an extension in prolog-irc. However i'm now considering just making this an integral part of the bot.

[eazar001]

Merging this from issue #9:

There needs to be some sort of structured local settings mechanism to provide more fine-grained behavior control of each extension.

[Anniepoo]

Prolog settings are per-module. Chatty already has some private settings

[eazar001]

Anniepoo says:

We need some sort of rules for extensions so they don't get in each other's way.

There's currently a defacto rule that lets each extension take a name to respond to

?search member/3

?chatty

but already we have chatty, which has a different rule of saying ?chatty then chatty responds to anything you say until ?chatty bye.
Given the nature of chatty, this seems a good design, but I just wonder if we're headed down some road to chaos rather than anarchy.

[eazar001]

I suggested this (with respect to an alternative to the cumbersome usage of target/2 and determine_recipient/3):

A more generic and unobtrusive solution is needed here. I should design a more robust abstraction.

[eazar001]

Future plans for state management (this checklist will continuosly evolve as time progresses):

• 1) Inclusion of a reflection interface ... to enumerate known and loaded extensions. This interface of course is present to the user of the bot, but the interface should also bridge those external to the system (i.e. others in the channel).
• 2) Extensions should register reserved keywords that are critical to individual operation. This would help tremendously with necessary exclusivity so that unwanted interference doesn't impede user interaction. This need is consequent of the inherent asynchronicity of the bot. At any rate, a suggestion like this, and perhaps other components to build up a comprehensive rule system for proper operation would be a good thing to implement.
• 3) An alternative to lumbering constructs like the lever devised between target/2 and determine_recipient/3 is needed here. The alternative doesn't necessarily have to be utter replacement, just acceptable improvement at the very least. This overlaps significantly with point (2) in my eyes.
• 4) Also general shared state attributes such as number of extension-specific requests and timeouts should be recorded in an organized way as well. Attributes should be organized with reference keys. Dynamic facts used in conjunction with gen_sym/2 generated IDs could be a potentially useful combination here.
• 5) Extensions should have the option to register records that register a user's nickname to some information (i.e. some long segmented text from wikipedia, or a dictionary). Simple dynamic facts asserted in state userspace should suffice for such a job. Delayed and/or controlled output, for example, can be pushed out of the asserted space and queue into the IRC channel, so to speak. It's obviously that memory leaks might be a problem here, so it's necessary that each user is tracked by some sort of timer mechanism to retract information after a specified period of time. These time periods should be flexible across groups.
• 6) Issue yesbot needs an anti-repeat #37 addresses a concern with redundant notifications in certain circumstances. I think this can be handled (not necessarily using the same proposed mechanism) under this general category of enhancements.