130
rdination we will be capable of! What collaboration!
What *SELF-ORGANIZATION* we will be capable of when we can FINALLY COMMUNICATE CLEARLY and UNIVERSALLY.
We will be able to THINK with NEW CLARITY, and GAIN from the THINKING OF OTHERS.
Finally, at the end of the chapter, is the Geek Block.
GEEK BLOCK BEGINS
A possible architecture for TODAY.
I would code it in C# or Python.
system resources (printer) | TXT XML YAML SQL by file | ___/___/___/____/ \ | / INPUT----()---Database Access--+-- Lists / | \-- Entrees by GUI/CLI | \-- Subjects/IDs | \-- Output Configuration Output... | | . changed duplicates pages | | ' | | . -------------------- . Page Output System - - | | .doc .txt
You can input by file (changes), or by GUI/CLI (invocation, diognostics, output requests).
INPUT
Change requests: * add entries * change/update/annotate entries * move entries * mark to archive * new subjects
Output requests: * request duplicates of pages * request all pages updated since last request
Invoaction: * update from the latest request, and return a receipt.
Diagnostics: * debug information * manual vision/manipulation of internal databases * database statistics
DATABASE
Abstract the database system. May want to use pure interfaces, or a bridge pattern.
Can use XML, YAML, SQL, TXT file, or whatever, to be the form of the database.
I myself would go with YAML.
The database keeps track of your lists (TOCs, speed lists), the entrees in the lists (Speeds, TOC entries; their contents, hints, and titles), the subjects & their abbreviations, and the present output configuration (txt? doc? rtf? font? size? color? blahblahblah?).
OUTPUT SYSTEM
START SIMPLE. While you could do a lot of cool tricky output things, I'd start dirt simple. For a word.doc output, just say "2 columns, point 8 text, tabbed, fit 70 to the page."
Don't worry about making optimal use of space for now- that gets tricky w