 
 
 ;; A signal sampler might have functions that let you plug in your own signal channels that you mix/merge/alt
-;; whatever, to gate vs critical system control messages.
+;; whatever, to gate vs critical system control events.
 
 
 ;; ## Public API around dispatchers
 
 (defn dispatch!
-  "Dispatches message on the dispatcher component at the given level (:default if unspecified)."
-  ([dispatcher message level]
-   (protocols/dispatch! dispatcher message level))
-  ([dispatcher message]
-   (protocols/dispatch! dispatcher message :default)))
+  "Dispatches event on the dispatcher component at the given level (:default if unspecified)."
+  ([dispatcher event level]
+   (protocols/dispatch! dispatcher event level))
+  ([dispatcher event]
+   (protocols/dispatch! dispatcher event :default)))
 
 (defn dispatch-error!
-  [datview message]
-  (dispatch! datview message :error))
+  [datview event]
+  (dispatch! datview event :error))
 
 
 (defn event-chan [dispatcher]
-  "Get the message channel for a dispatcher"
+  "Get the event channel for a dispatcher"
   (protocols/dispatcher-event-chan dispatcher))
 
 

;; He'll knock ya lights out and leave ya swimmin with the fishes.
;; So don't mess around with him, ya hear?

;; The dispatcher is what gives us control over how messages are processed.
;; For most applications, a pretty straightforward mechanism should work.
;; Events should get handled in the order they are fired in.
;; Simple.

;; But suppose you wanted more control over the situation?
;; Perhaps you want for error and/or warning messages to be handled with higher priority than other queues of
;; messages?
;; Perhaps you are sampling from an input device, and don't want for it's signal to swamp out other important
;; functionality?
;; Perhaps you want to be able to plug in your own crazy rube goldberg core.async pipeline for some malicious

    (let [component (assoc component
                           :default-chan (or default-chan (async/chan 100))
                           :error-chan (or error-chan (async/chan 100))
                           ;; This should have no buffer so that it doesn't grab a dispatch event and put it in
                           ;; the buffer just before an error event comes in
                           :event-chan (async/chan))])
    (go-loop []
      ;; Hmm... this actually doesn't have the semantics we want, since 1 default chan event could get
      ;; through before the event chan is ready to take yet
      (let [[event chan] (async/alts! [error-chan default-chan])]
        (async/>! event-chan event)))
    component)
  (stop [component]
    component)
  protocols/PDispatcher
  (dispatch! [component event level]
    (go
      (async/>! 
        (if (= level :error) error-chan default-chan)
        event)))
  ;; Here, the event chan is just the dispatch chan...
  (dispatcher-event-chan [component]
    ;; Don't know if this will compile properly TODO
    event-chan))

(defn new-error-priority-dispatcher
  "Creates a new ErroPriorityDispatcher. Can customize :default-chan and :error-chan through options.
  Idea is that Reactor will get error events before other queued events, but the mechanism is a little flawed.
  Currently, it's still possible for a non error event to get through before the reactor is ready to consume from the event-chan.
  May need to adjust the protocols."
  ([options]
   (map->ErrorPriorityDispatcher options))
