commit dd170ff94b02ee40893bf7a99e283950938fed6c
Author: Marc Dequènes (Duck) <Duck@DuckCorp.org>
Date:   Sat Feb 26 19:16:36 2011 +0100

    [-] added dev ideas

diff --git a/IDEAS b/IDEAS
new file mode 100644
index 0000000..d56f9a8
--- /dev/null
+++ b/IDEAS
@@ -0,0 +1,126 @@
+
+Tasks:
+  - wait notif on multiple channels:
+    by registering the same callback on multiple channels,
+    and unregistering all of them at once later. there is
+    a chance of throwing the callback twice on different
+    channels, so it is impossible to unsure a single call
+  - work on sending notif to peers through special channels
+
+Postman:
+  - process schema (without intermediate bot for command processing):
+
+                                                                                (reschedule)
+                                                                            /---------<--------\
+                                                                            |                  | temp internal err
+      IMAP                                                                  |                  |
+      retrieval  -----> incoming mail queue ------> process mail ----> order queue ----> process order
+                                                         |                                     |
+                                                     err |                                     | order err or fatal int err
+                                                         |                                     |
+      SMTP reply <------ outgoing mail queue <-----------/------------------<------------------/
+
+    each queue is an internal channel, each processor is a task.
+
+MapMaker:
+  - API:
+    /Services/DNS -> named info
+    /Services/DNSSEC -> DNSSEC system info
+    /Services/ZoneEditor -> Helper for zone content manipulation out of named scope
+      /validate(<zone_name>, <zone_content>)
+      /alter(<zone_content>, <recipe>)
+    /Zones
+      /? -> search zone, params are string/numeric/boolean/regex criterias ANDed
+      /<zone> -> abstraction of a zone (DNS, DNSSEC, content…)
+        /content -> view zone full content
+          /? search RR
+        /content=(<zone_content>) -> change zone full content
+        /alter(<recipe>) -> recipe is a DSL-like list of commands
+  - diag functions for services
+  - distinguish presence of signed zone and which zone is really advertised by DNS
+
+Guard (auth bot):
+  - process for delegating auth (needs polish):
+    subject: Bot1 ask Bot2 to do a <job> for another <id>
+    1) Bot1 tries to ident on behalf of Guard
+    2) Guard fetch info into Librarian (LDAP)
+    3) Librarian can tell if Bot1 auth is OK
+    4) if so, Guard tells Bot1 he is identified
+    5) Bot1 ask Bot2 to do a <job> as another user using <id> token
+    6) Bot2, which is supposed to already be identified on behalf of Guard,
+       as seen previously with Bot2, ask Guard if this <id> token is valid
+    7) if valid, replies OK to Bot1 and schedule the job
+    the <id> token can be on for himself, ro one acquired from Guard for
+    another user if Bot1 has enough privileges
+
+Actions:
+  - DECLINE:
+    needs better definition and codes to distinguish temporary and fatal,
+    errors, so as to know when to abandon and when to reschedule
+  - CALL:
+    + exist? / info / act ???
+    + a reply could give a ref to another node, but how?
+
+Conversation:
+  - when disconnect (needs polish):
+    + without ACK => error (lost), but we may add a mechanism to retry
+                     a few times with a delay (increasing delay)
+    + with ACK => save callback for when reconnected
+    + pending ACK => drop
+    + pending tasks => do, reconnect when result ready by ourselves
+
+Threads:
+  - goals:
+    + auth token (negociated with Guard)
+    + I18n parameters (list of translation prefs)
+
+Tasks:
+  - inheritance: thread data (auth token, I18n prefs…)
+
+API:
+  - node def:
+    + name
+    + array of names
+    + regex: matching names
+    + nil: method_missing-like catchall
+  - client API:
+    + exists?
+    + call
+    + [<name>]: sub-node
+  - define_interface:
+    support list/ranges/regex for version and define several
+    supported API a client could choose between
+
+Channels:
+  - reorganize channel names
+  - enforce msg[:from] with 'task/<task-name>' in send_notification
+
+Logging:
+  - mass rework needed, with better "area" identification
+  - multiple hierarchical loggers, using format to add prefixes
+  - use dep-injection to propagate sub-logger to areas where all
+    info needed to recreate prefixes are not available
+  - use more log flags to activate debug only on specific areas
+
+Alerts:
+  - actions can lead to problems, which need to be processed to dispatch
+    proper messages to the user but also generate alerts to administrators.
+    For example, of the DNS system is not working well, we need to reply
+    the user the service is not working well and his/her demand connot be
+    processed, without any technical detail, but the DNS admin should be
+    alerted in order to repair it. Moreover, the overall CH admins should
+    be alerted of bot problems and major failures. Moreover, the DNS zone
+    admin could also be willing to receive alerts concerning the zone
+    he/she is in charge of.
+  - we need a process to generate events, and filter them to generate
+    wanted alerts depending on area/severity/… to the right recipients,
+    with a message adapted to the recipient
+  - process events (needs polish):
+
+    actions ---> events ---> event filter ---> alert ---> media (mail/jabber/…)
+                   |             /|\                       /|\
+                   |              |                         |
+                  \|/             |                         |
+                  log             \------------------- admin prefs
+
+  - custom rules are needed to filter useful events
