+ Wir sollten darauf achten, auf den oberen Ebenen die Anzahl der Kategorien knapp zu halten — um eine gewisse systematische Auffindbarkeit zu gewährleisten; im Gegenzug dazu sind weitere Unterkategorien auf tiefer geschachtelten Ebenen eine praktisch kostenlos verfügbare Ressource, da die Kapazität eines Baumes exponentiell mit der Tiefe wächst +
+ + ++ Wenn die Design- und Archtektur-Bereiche zu sehr in die Details abgleiten, fächern sie sich in technische Belange auf, welche nicht mehr so recht systematisch in eine Kategorie passen wollen. Für die technische Dokumentation ist das kein Problem, denn diese ist ohnehin quantitativ ausgelegt. +
+ + ++ wie so oft hatte Christian eine ganz pfiffige Lösung, die zu kurz greift aber in die richtige Richtung zeigt (und auf die man erst mal kommen muß!) +
+ + ++ es gibt einen RfC: »WebsiteSupportMarkup« +
+ + ++ Die Implementierung braucht sehr wahrscheinlich einen kompletten Scan über alle Dokumente; das zu vermeiden führt direkt in ein DB-basiertes CMS. Daher, gemäß KISS sollte man erst mal versuchen das zu implementieren und beobachten, wie groß der Schmerz ist. Auch Menuegen selber war mal in zwei Tagen implementiert, ist schwer zu warten, aber erfüllt seinen Zweck inzwischen seit mehr als 10 Jahren +
+ + ++ Das größte Problem ist wohl, daß wir nicht genau wissen, was wir brauchen (abgesehen von der Vorstellung, irgenwie magisch funktionierende Cross-Links zu bekommen)... +
++ nun sind wohl 10 Jahre vergangen +
++ und das Problem besteht unverändert +
+ + ++ ...was aber vor allem daran liegt, daß ich allein bin und für mich sowiso alles per Mindmap organisiere; daher konnte ich das Problem bisher »aussitzen« — was aber leider dazu geführt hat, daß das TiddlyWiki (und meine Mindmap) ins Unermessliche gewachsen sind. Dennoch ist das Problem eigentlich brennend ernst: außer mir blickt keiner durch, und ohne mich findet niemand die Ergebnisse der umfangreichen Konzeptionsarbeit. +
+ + ++ Dieser Vorschlag stammt von Christian, und (selbst wenn der Vorschlag zunächst in zweifelhaftem Kontext stand) — es ist die einzige bisher vorgeschlagene Lösung, die mit einfachen Mitteln umsetzbar ist, letztlich sogar ohne jedwede Automatisierung +
+ + ++ ...all die weiteren seinerzeit hitzig diskutieren »Killer-Features« sind meines Erachtens Extras, die man oben drauf setzen kann; auch Übersichts- und Kategorieseiten erreicht man letztlich wieder über einen ID-Link. Der einzige Knackpunkt ist, das Eingangs-Format der Links so hinzubekommen, daß es tragfähig ist. +
+ + ++ Micro-HTTPD expandiert nicht automatisch *.html +
+ + ++ Aus mehrerlei Gründen +
++ »solange Vorrat reicht« — die ganze Frage der Duplikat-Resolution kann später auf technischer Ebene gelöst werden, solange es nur für jede verwendete ID einen Link gibt +
+ + ++ Stichworte allein sind ein flat namespace +
+ + ++ Das wäre eigentlich eine schöne Lösung, die uns weiterhin ein Content-Management-System erspart: wir erzeugen beim Seiten-Rendern eine Linkfarm, und die Links werden anhand von Tags aufgelöst, die in den Seiten als Kommentar stehen (ähnlich wie derzeit die Steuerung des Menüs) +
+ + ++ Seinerzeit wollte Christian das mal eben schnell in Lua implementieren, war aber am nächsten Tag zurückgerudert (als ihm klar wurde, daß die eigentliche Aufgabe schon etwas komplexer ist). Dann wollte sich Benny darum kümmern, ist aber bei einem Glossary-Generator steckengeblieben. Und ich — ich würde das wohl in 1-2 Wochen hinbekommen, würde dafür aber auch Menuegen neu schreiben, weil beide Aufgaben gleichermaßen eine Traversierung aller Sources erfordern. Meine Sorge dabei ist, daß das ein Performance-Bottleneck wird; denn dann brauchen wir inkrementelle Verarbeitung und damit eine Datenbank — und würden dann selber ein Content-Management-System schreiben. +
+ + ++ Und das Problem hierbei ist so typisch Christian: „man kann dann ja mit Tags arbeiten!“ — Junge, ein System von Tags aufbauen, das für unsere Zwecke funktionert, das ist die eigentliche Aufgabe. +
+ + ++ Lumiera ist keine Plattform und kein Framework — wir haben lediglich Framework-artige Infrastruktur wie in jeder größeren Applikation +
+ + + ++ hier stimmt was nicht mit dem Link auf das allgemeine Essay +
+ + ++ Okt.2009 hatten wir eine Kooperation mit der ffis.de vereinbart; in den nächsten Jahren gab es ein paar Klein-Spenden, die wir aber nicht von der ffis abgerufen haben, da wir damals keinen Bedarf hatten (Idee war z.B. immer gewesen, einem Entwickler die Reise zum Treffen zu zahlen — aber die Beteiligten konnten die Reise zur FrOSCon immer problemlos selber zahlen). Das ist zwar schön für uns .... aber eine derart veraltete Spenden-Seite wirft ein schlechtes Licht auf uns! +
+ + +