Dikid

Eine weiterer Versuch eines Wiki (evtl auch für ticketsystem)), Blog und vor allem ((howto:ticketsystem). Ich will vor allem ein kaskadirende technische Anforderung haben. Erst mal soll alles einfache markdown files in einem filesystem sein, wenn gewollt git-versioniert, diese, wenn vorhanden und nötig mit einem webserver auslieferbar, dann einfache Indizierungen mit grep oder aus den den gitdiffs in files und ganz wenn das alles nicht performt am Schluss eine Spiegelung in einer noSQL Datenbank

Das ganze nennt sich dann Static Site Generator, aber warum bezogen nur auf statische Seiten, warum nicht auch ein tickestsystem. Das empfohlene Wheat könnte was sein.

Der reine CouchDB Ansatz funktioniert nur bedingt und es fehlen Features die Ikiwiki hat, aber vice versa.

{DIV(align=>left, width=>25%, float=>right, class="umijabox")}{DIV}

https://gist.github.com/3419470

Struktur

Speicherung als plain files (wie in ikiwiki) denn git kann mehr als codeverwaltung * Vorteil: man kann ohne ApacheMysqlPhp.js ran und kann bulk und cron jobs von der konsole aus machen * oder das ganze mit dropbox und git verheiraten. * git versioniert, protokolliert und verteilt * markdown als Speicherformat (von mir aus ein WYSWIG) * Filesystem übernimmt * Grundsemantik (''blog/2012/02/hello'', ''task/1234'', ''doku/world'') die auch in der dann http URL erscheint und bleibt * registrierte logische Filesystemsemantik, was man auf einem filesystem halt auch machen würde (''/task/_Archiv/9876'') die aber nicht (''/task/9876'') auf die URI durchschlagen * gewöhnliche Tags in Dateinamen, wie poormans datesort ('2012-06-06_hallo.md') die sich aber nicht ändern dürfen (also nicht die Prio). * gewöhnliche Tags in eine pseudo Fileextension(durch Punkt getrennt), wie Prio ('hallo.prio_1.ort_hauptplatz.parent_world.md') die sich ändern dürfen. Das bedeutet: alles bis zum ersten Punkt ist das Lemma/Name/ID, alles nach dem letzten Punkt die wirkliche Dateinamenserweiterung und der rest zwischen drin punkt-getrennte tags. (damit wird nicht grep sondern locate (schnell) und find (aktuelle) meine mapreduceDB ;))) Ist jetzt nur die Frage wie man die Files schadlos (per webserver) in git umbenennt und verhindert das man Dublikate vor dem ersten punkt bekommt....? <--- dämliche Idee.

Dadurch darf man in den URIs keine Punkte etc verwenden, das ist aber generell ein reserviertes Zeichen.

tags

tags machen aus einem static-site-generator ein frmwrk;) Als syntax nutz ich mal outermarkdown (draft) die sich auf die Seite oder Zeile referenzieren. Die Tags solen aber nicht in einem extra view/directory/file gespeichert werden, sonern in ihrem 'Ziel'. Wenn jemand im Artikel "Zeltlager.md" rein schreibt "* Kocher besorgen klml# prio#1" dann soll in der Datei klml.md und prio.md jeweils ein eintrag auf Zeltlager stehen. Am besten acnhe einem bestimmten Trennzeichen

Entweder man erstellt diesen manuellen index jedesmal neu, was aber mit vielen Fiels teuer weird, da man jedesmal alle tags öschen muss und alle schreiben. Oder man schreibt nur die dazugekommenen und löscht die entfernten. Welche das sind, erhält man indem man die Datei vor dem Schreibvorgang speichert und mit der nach dem Schreibvorgang vergleicht. Ein Diff aus dem Repo hat das shcon von Haus aus.

Aggregation

  • markdowncompiler (wie ikiwiki und cocuhdb)
  • Markdown mit Server Side Include (und leider perl, geht das nicht ohne) für header und footer
  • in C für nginx
  • Views mapenreducen aus Seiten oder Zeilentags, aber wie mapenreducen?
  • gibt es einen einzelnen view compiler
  • als JSON Ausgabe
  • -> http://mustache.github.com/
  • grep mit regexp
  • nicht nach dem Schreibvorgang, denn dann würde ich keine taglöschungen mitbekommen
  • sondern er soll aus dem git diff den ++ und denn -- teil parsen. Alles aus dem -- entferne , aus dem ++ addieren
  • --> nochmal sorten
  • und ab und zu dann doch alles per cron parsen lassen
  • aus einer gitapi (C, auch PHP oder glip)raus

Webserver

Neben dem direkte betrachten der files, eine html darstellung. Nginx oder direkt node.js für static files

Ein einfach Access Modell nur über Namensräume (alles andere ist zu kompliziert) und htaccess

Allerdings muss ich die htaccess oder oAuth user dem git schreibprozess mitgeben TODO?

Alle Schreibvorgänge werden: * mit JS und PUT an den PUT-lauschenden Webserver (z.B. nginx) gesendet. * aber im Namen des htaccess-Users ins git commited ?? (über File Alteration Monitor

Umsetzung

Ein Versuch mit git, libmarkdown2 (ein standrad markdown converter unter ubuntu, man kann auch pandoc etc nutzen) und nginx als webserver.

  • Mittels jQuery wird der md-Quelltext clientseitig in eine textarea geladen
  • per http-PUT das file einfach überschrieben (access dann bitte mit htaccess machen;)
  • commit
  • ich bringe dem webserver bei zu commiten (suche ich gerade was für nginx TODO)
  • netcat lauscht auf port 8080, den der nginx mit-triggerd und bashed den commit
  • der git-hook feuert die markdown aber nur auf die geänderten Dateien (''git diff HEAD~2'') um die dem nginx die html zur Verfügung zustellen

dazu gibts da draussen

inhaltsstruktur

privat nur in deinem repo auf deinem rechner, deinem handy, deinesm homeserv, sonst nirgends!

log diary

me my store purse wallet heart

proj

todo

personal pers per

public auf einem webserver blog: wir/ich sagen was und du darfst evtl kommentieren wiki: alle schreiben mit an einem dokument

tick: task: taskverwaltung

faq, wenns denn sein muss

version vs comment

Soll man nun, wikimäßig, ein dokument versoniert aktualisieren oder kommentarartig (blog/forum/ticket) eine neues Dokumente anhängen.

Beides geht. Mediawiki z.B. nutz als Diskussionsystem ''eine'' zusätzliche Diskussionseite, auf der alle, sogar ineinandere rumschreiben, das ist nicht perfekt, aber funktioniert.

Kommentare haben zwar den Vorteil das jeder beitrag einer person und zeit zugeordnet werden kann, aber wenn man das bestehnde nicht bearbeiten kann, kann man nur daraf referenzienen.

was soll versionietr werden: * alles was zum aktuellen zeitpunk wichtig ist * Historie/log wie commits, meilensteine

was commeniert: * abhängige Aufgaben die eine andere machen könnte