Der Multiplexer sollte so flexibel wie moeglich sein:
*Logging supporten (ggf. auch per Post konfigurierbar) -DooM 12:25, 31. Okt. 2013 (CET)
*"Abonnements supporten" so dass einzelne Datenquellen selektiert werden koennen und ein Oputput nicht alle enthalten muss -DooM 12:25, 31. Okt. 2013 (CET)
+** Ich hatte mir als User-Interface eher den Multiplexer gedacht. Sprich: Will ich auf einem Display X Datenquelle Y anzeigen, sage ich das genau dort und das Routing wird entsprechend veranlasst. [[Benutzer:Drahflow|Drahflow]] ([[Benutzer Diskussion:Drahflow|Diskussion]]) 11:02, 2. Nov. 2013 (CET)
*Aggregations Features bieten um Daten vor dem Anzeigen bereits Serverseitig aufbereiten zu koennen (Durchschnittswerte/Extrema/Mittelwerte/Integrale usw.) -DooM 12:23, 31. Okt. 2013 (CET)
+** Ja. Insbesondere hätte ich gerne Predictors, wie z.B. KALMAN-Filter (Junge), um dann Abweichungen detektieren zu können. [[Benutzer:Drahflow|Drahflow]] ([[Benutzer Diskussion:Drahflow|Diskussion]]) 11:02, 2. Nov. 2013 (CET)
== Datenformat ==
Hmm waere so etwas wie YAML nicht deutlich angenehmer als Tabellen? -DooM 12:25, 31. Okt. 2013 (CET)
<pre>
-msg1:
+msgID: 1
type: geo
streamID: $UUID
log: true
username: Drahflow
time: 1383097977.120
-msg1:
+msgID: $UUID
type: geo
pos:
lat: 50.2
time: 1383097977.125</pre>
* streamIDs lassen sich abonnieren und das LOG feature bedingt sie um sie zuordnen zu koennen.
+* gelogte MSG haben immer eine msgID auch wenn der sender keine sendet und lassen sich damit immer wieder abrufen
* alle RAW daten muessen human readable sein wenn dispFormat nicht definiert ist
-* es muss einen Prozess geben neye types zu definieren (gemeinsam/demokratisch) und ggf. auch automatisiert.
+* es muss einen Prozess geben neue types zu definieren (gemeinsam/demokratisch) und ggf. auch automatisiert.
=== x-poserspace/scalar ===
X-column-*-label: Temperature