Opened by renee at 2004-01-02 21:50
User since
2004-12-12
30 Artikel
BenutzerIn
![[default_avatar]](/battie/theme/default/default_avatar.gif)
2004-12-12
30 Artikel
BenutzerIn
Hallo Leute
Hier diskutieren wir über MORK.
Was es ist, wie es funktioniert, wozu es nützlich (!) ist.
Hier meine Forschungsergebnisse der letzten Tage:
-Mork ist eine Art Datenbanksystem, das von Mozilla verwendet wird. Es dient zum Speichern der Adressbücher im Mailprogramm und der history im Browser.
-Mork wird vom Publikum im Internet als das schlimmste, schrecklichste, unintelligenteste Ablageformat angesehen, dass man je gesehen hat. Bemerkungen darüber sind extrem spöttisch oper hasserfüllt.
- Mork ist voll verwirrend. Es verwendet die selben Zeichen für verschiedene Zwecke, Informationen werden so kompliziert gespeichert und komprimiert, dass man schwer alles versteht.
- Grundsätzlich wird Mork in ASCII abgespeichert. Es kann von "jedem Editor" gelesen und geschrienen werden. Es verwendet ein seltsamen "Schlüssel-Wert"-System. Dabei haben die Schlüssel hexadezimale Zahlen als Werte, die auch in ASCII-Zeichen gespeichert werden. Das Ganze ist eingepackt in runde Klammern.
Zusammengehörende Blöcke von runden Klammern werden mit spitzen Klammern eingefasst. Zum Teil auch mit geschweiften und mit eckigen. Wer weiss, warum wo welche stehen..
Es können auch Schlüssel sich auf Schlüssel eines anderen Blocks beziehen. Und da wird es verwirrend:
Oder eine Zuweisung kann leer sein:
Daneben hat es plötzlich schleierhafte Zeichen, die irgend etwas markieren (wahrscheinlich):
Zum Adressbuch von Thunderbird:
Das Adressbuch ist in 3 Teile aufgeteilt. Am besten ist es, wenn du ein neues Adressbuch mit 1 Eintrag gründest und es mit einem Editor ansiehst.
Teil 1 enthält zuerst eine Bemerkung (glaube ich) und gibt sich zu erkennen:
Dann folgt in der Block_eröffnung "<"eine mir schleierhafte Erklärung (a=c) und als Kommentar (//) die Angabe vom iso 8859-1, die es laut Posts aus anderen Foren gar nicht mal einhält.
Anschliessend folgt Block 1 mit der Initialisierung aller Felder, die eine Adresskarte in TB hat (Hier nur der Beginn und das Ende:)
Am Ende dann der Schluss des Blocks 1 mit ">".
Offenbar spielt die Reihenfolge innerhalb des Blocks keine Rolle, auch nicht Linienumbrüche.
Soweit ist es einfach und in jedem Adressbuch gleich. Nun aber wird es echt komisch. (Ich habe nicht verstanden, was das soll, darum sag ich nicht "voll daneben")
Wenn nur einzelne Karten gespeichert sind (so wie in deinem erstellten Beispiel), folgt jetzt so eine komischer Block, von dem ich nicht weiss, was er soll.
Gefolgt von der Adress-Karte (mit krytischer Eröffnung!):
Und den Daten (Fragt mich nicht über Details):
Wenn du noch Vor-und Nachnamen eingegeben hast, sind die auch mit weiteren Schlüsseln gespeichert.
Bestimmt merkst du jetzt, warum ich das System doof finde. Die Schlüssel haben in diesem Block wieder die selben Zahlen wie oben bei der Initialisierung der Kategorien..
Und schliesslich der Zuweisung aller Schlüssel aus Block 1 (Initialisierung) zu den Schlüsseln aus Block 2 (einzelne Karte). Und zwar auch dann, wenn gar kein Wert gespeichert ist. Man müsste doch meinen, wenn die Reihenfolge keine Rolle spielt, sollte man auch keine leeren Werte speichern müssen, nebenbei..
Hier also nur Anfang und Schluss (mit krytischer Einleitung und kryptischem Schluss):
Was genau passiert ist mir in Einleitung und Schluss wie gesagt nicht klar, nur dass "-1" und "1" die erste Karte zu meinen scheinen. Der Mittelteil ist klar. (Schlüssel-Schlüssel-Zuweisungen, siehe oben)
Wenn du jetzt tief durchgeatmet hast, etwas Kühles zu Trinken besorgt hast und Lust hast auf grosses Kopfschütteln, füg deinem Adressbuch einen zweiten Eintrag hinzu. NUR EINEN!
Aha! Alles klar, denkst du. Jetzt kommt einfach unten ein zweiter Block hinzu, alles klar. Wenn du jetzt abenteuerlustig bist, kannst du etwas damit herumspielen und Werte verschieben, verändern usw. und sehen, was Thunderbird damit macht. Achtung! Beim Speichern muss TB immer geschlossen sein, sonst ist das File gesperrt.
Wunderbar habe ich gedacht, so wie du vielleicht und habe die 3. Karte mit copy&paste selbst hergestellt. Aber oh Schreck! TB konnte das Adressbuch nicht mehr lesen!
Wenn du jetzt in TB einen dritten Eintrag hinzufügst, entdeckst du die geheimnisvolle Welt des MORK erst richtig. Jawoll! Er "komprimiert" die Daten! Warum und wieso weiss der Himmel. Auf den ersten Blick scheint er damit Platz zu sparen und man möchte ein lobendes Wort verschwenden. Verschwenden! Schau mal ein langes Adressbuch an und sag dann deine Meinung. MORK mischt das zusammengefasste Format mit den Einzeleinträgen. Himmel hilf!
Wie gesagt, vielleicht habe ich es auch nur nicht richtig verstanden.. Allerdings findet man im Internet nicht wirklich einer , der für MORK eine Lanze brechen möchte. Es ist wie mit MS: Weils läuft, schimpfen nur ein paar, aber so richtig toll finden tuts keiner.
Zum "zusammengefassten" Format:
Zuerst kommen die Informationen zu den einzelnen Karten, denen aufsteigende Nummern verliehen werden. (Eigentlich hex, aber es scheint MORK egal zu sein, wenn man auch nur Dezimalzahlen verwendet. MORK ist tollerant!)
Und oh Wunder! Die kryptischen Einleitungen und Schlüsse sind verschwunden. Vielleicht ist der liebe Zauberer gekommen oder der böse Drache. Hauptsache, sie sind weg und stören nicht mehr. Mein böser Verdacht ist aber vielmehr, dass es sie gar nicht wirklich braucht, wenn man sie weglassen kann, und sie nur dazu dienen irgendwelche geheimnisvollen Gelüste des bösen MORK zu befriedigen..
(Ich habe nur Mailadressen gespeichert, natürlich könntest du auch Vornamen speichern usw. Die Zahlen werden dann einfach immer grösser und nie dürfen zwei den selben Schlüssel haben, sonst ignoriert MORK den Rest oder wird unlesbar.)
Nach den Informationen wieder eine lustige Einleitung mit Klammern auf, Klammern zu, mir schleierhaften Zuweisungen und bestimmt ganz wichtigen Informationen drin.
Und jetzt das beste: Zu jeder Karte ein vollständiger Block mit allen Schlüssel-Schlüssel-Zuweisungen wie im Beispiel mit nur 1 Karte. Weil du's begriffen hast nur die erste Karte.
Spannend ist die viertletzte Zuweisung auf der ersten Linie:
Sie sagt: "89 aus Block 1 (=Primary Email) gehört zu 82 aus Block 2 (=hallo@bello.ch). Schlicht göttlich.
Der letzte Eintrag "(^BB=1)" scheint zu sagen, dass wir uns in der ersten Karte befinden, was wir aber schon längst wissen, denn schliesslich beginnt alles mit der Zahl 1 (Gleich nach der eckigen Klammer). Clevere werden bemerken, dass das Minus vor der 1 (aus der "Einzelspeicherung") verschwunden ist. Was auch hier den Schluss zulässt, dass es eigentlich unnötig war.
Auf jeden Fall.
Nun zur guten Nachricht: Auch wenn MORK bei grossen Adressbüchern immer nur einige Karten in der zusammengefassten Form speichert und einige zuunterst in der Einzelspeicherung, ist es möglich, alles in zusammengefasster Speicherung zu schreiben.
Wie schon erwähnt muss man auch nicht unbedingt hex-Schlüssel verwenden in den Informationen in Block 2.
Spiel doch mal ein wenig herum mit einer foreach-Schleife, die 5 oder 10 oder 100 Einträge mit zufälligen Mailadressen oder Vornamen oder usw. füllt.
Du musst lediglich daran denken, genau die richtige Anzahl Blöcke Schlüssel-Schlüssel-Zuweisungen (Block 3) zu haben. Die kryptische Einleitung kannst du einfach abschreiben.
So lange man nur "von aussen" ins Adressbuch schreibt, ist alles wunderbar. Mischt man aber das "Reinfummeln" mit ordentlichem Einfügen via TB-Adressbuch-Verwaltung, gibt es ein göttliches, unlesbares Durcheinander, weil TB natürlich immer wieder zur gemischten Speicherung zurückkehrt.
Für mich war es spannend, zu "morksen" und es dient meinen Zwecken, von aussen (mit perl natürlich) ein lesbares Adressbuch zu schreiben. Interessant wäre es sicher, das Ganze so weiter zu entwickeln, dass volles Lesen und Schreiben möglich würde. Die Idee CPAN-Modul ist sicher grossartig. Wenn ich doch sehr hoffe, dass die Arbeit bald überflüssig wird, weil Mozilla zu einer vernünftigen (bekannten) Datenbank wechselt, für die bereits Anbindungen bestehen.
Zum Schluss ein paar Probleme & Fragen, die ich euch vorläufig gerne zum Weitertüfteln überlassen würde:
- Lösch mal eine Karte und schau, was MORK jetzt tut!
- Nach welcher Logik entscheidet er sich für eine der beiden Speicherungsarten?
- Welche Logik steckt hinter den Block-Einleitungen?
Wär mir ein Vergnügen, von euch zu lesen.
Vielleicht gründen wir sogar eine MORK-Community und treffen uns bald in einem tiefen, unheimlichen Zauberwald zum ersten MORKCOM-Treffen. An einem Freitag-dem-13., zu Vollmond und an Wintersonnwende, versteht sich.
GRMORKGRÜÜSSSSEEEE (Mit tiefer, lauter, gefährlicher Stimmer)
M.
Hier diskutieren wir über MORK.
Was es ist, wie es funktioniert, wozu es nützlich (!) ist.
Hier meine Forschungsergebnisse der letzten Tage:
-Mork ist eine Art Datenbanksystem, das von Mozilla verwendet wird. Es dient zum Speichern der Adressbücher im Mailprogramm und der history im Browser.
-Mork wird vom Publikum im Internet als das schlimmste, schrecklichste, unintelligenteste Ablageformat angesehen, dass man je gesehen hat. Bemerkungen darüber sind extrem spöttisch oper hasserfüllt.
- Mork ist voll verwirrend. Es verwendet die selben Zeichen für verschiedene Zwecke, Informationen werden so kompliziert gespeichert und komprimiert, dass man schwer alles versteht.
- Grundsätzlich wird Mork in ASCII abgespeichert. Es kann von "jedem Editor" gelesen und geschrienen werden. Es verwendet ein seltsamen "Schlüssel-Wert"-System. Dabei haben die Schlüssel hexadezimale Zahlen als Werte, die auch in ASCII-Zeichen gespeichert werden. Das Ganze ist eingepackt in runde Klammern.
Code: (dl
)
(8A=Mein Eintrag)
Zusammengehörende Blöcke von runden Klammern werden mit spitzen Klammern eingefasst. Zum Teil auch mit geschweiften und mit eckigen. Wer weiss, warum wo welche stehen..
Code: (dl
)
<(B8=Custom4)(B9=Notes)(BA=LastModifiedDate)(BB=RecordKey)>
Es können auch Schlüssel sich auf Schlüssel eines anderen Blocks beziehen. Und da wird es verwirrend:
Code: (dl
)
(^89^82)
Oder eine Zuweisung kann leer sein:
Code: (dl
)
(^83=)
Daneben hat es plötzlich schleierhafte Zeichen, die irgend etwas markieren (wahrscheinlich):
Code: (dl
)
(k^BE:c)(s=9)
Zum Adressbuch von Thunderbird:
Das Adressbuch ist in 3 Teile aufgeteilt. Am besten ist es, wenn du ein neues Adressbuch mit 1 Eintrag gründest und es mit einem Editor ansiehst.
Teil 1 enthält zuerst eine Bemerkung (glaube ich) und gibt sich zu erkennen:
Code: (dl
)
// <!-- <mdb:mork:z v="1.4"/> -->
Dann folgt in der Block_eröffnung "<"eine mir schleierhafte Erklärung (a=c) und als Kommentar (//) die Angabe vom iso 8859-1, die es laut Posts aus anderen Foren gar nicht mal einhält.
Code: (dl
)
< <(a=c)> // (f=iso-8859-1)
Anschliessend folgt Block 1 mit der Initialisierung aller Felder, die eine Adresskarte in TB hat (Hier nur der Beginn und das Ende:)
Code: (dl
)
1
2
3
(B8=Custom4)(B9=Notes)(BA=LastModifiedDate)(BB=RecordKey)
...
(B5=Custom1)(B6=Custom2)(B7=Custom3)>
Am Ende dann der Schluss des Blocks 1 mit ">".
Offenbar spielt die Reihenfolge innerhalb des Blocks keine Rolle, auch nicht Linienumbrüche.
Soweit ist es einfach und in jedem Adressbuch gleich. Nun aber wird es echt komisch. (Ich habe nicht verstanden, was das soll, darum sag ich nicht "voll daneben")
Wenn nur einzelne Karten gespeichert sind (so wie in deinem erstellten Beispiel), folgt jetzt so eine komischer Block, von dem ich nicht weiss, was er soll.
Gefolgt von der Adress-Karte (mit krytischer Eröffnung!):
Code: (dl
)
@$${1{@Und den Daten (Fragt mich nicht über Details):
Code: (dl
)
<(83=1)(81=)(82=hallo@bello.ch)>
Wenn du noch Vor-und Nachnamen eingegeben hast, sind die auch mit weiteren Schlüsseln gespeichert.
Bestimmt merkst du jetzt, warum ich das System doof finde. Die Schlüssel haben in diesem Block wieder die selben Zahlen wie oben bei der Initialisierung der Kategorien..
Und schliesslich der Zuweisung aller Schlüssel aus Block 1 (Initialisierung) zu den Schlüsseln aus Block 2 (einzelne Karte). Und zwar auch dann, wenn gar kein Wert gespeichert ist. Man müsste doch meinen, wenn die Reihenfolge keine Rolle spielt, sollte man auch keine leeren Werte speichern müssen, nebenbei..
Hier also nur Anfang und Schluss (mit krytischer Einleitung und kryptischem Schluss):
Code: (dl
)
1
2
3
4
5
6
{-1:^80 {(k^BE:c)(s=9)}
[1:^82(^BD=1)]
[-1(^83=)(^84=)(^85=)(^86^80)
...
(^BB=1)]}
@$$}1}@Was genau passiert ist mir in Einleitung und Schluss wie gesagt nicht klar, nur dass "-1" und "1" die erste Karte zu meinen scheinen. Der Mittelteil ist klar. (Schlüssel-Schlüssel-Zuweisungen, siehe oben)
Wenn du jetzt tief durchgeatmet hast, etwas Kühles zu Trinken besorgt hast und Lust hast auf grosses Kopfschütteln, füg deinem Adressbuch einen zweiten Eintrag hinzu. NUR EINEN!
Aha! Alles klar, denkst du. Jetzt kommt einfach unten ein zweiter Block hinzu, alles klar. Wenn du jetzt abenteuerlustig bist, kannst du etwas damit herumspielen und Werte verschieben, verändern usw. und sehen, was Thunderbird damit macht. Achtung! Beim Speichern muss TB immer geschlossen sein, sonst ist das File gesperrt.
Wunderbar habe ich gedacht, so wie du vielleicht und habe die 3. Karte mit copy&paste selbst hergestellt. Aber oh Schreck! TB konnte das Adressbuch nicht mehr lesen!
Wenn du jetzt in TB einen dritten Eintrag hinzufügst, entdeckst du die geheimnisvolle Welt des MORK erst richtig. Jawoll! Er "komprimiert" die Daten! Warum und wieso weiss der Himmel. Auf den ersten Blick scheint er damit Platz zu sparen und man möchte ein lobendes Wort verschwenden. Verschwenden! Schau mal ein langes Adressbuch an und sag dann deine Meinung. MORK mischt das zusammengefasste Format mit den Einzeleinträgen. Himmel hilf!
Wie gesagt, vielleicht habe ich es auch nur nicht richtig verstanden.. Allerdings findet man im Internet nicht wirklich einer , der für MORK eine Lanze brechen möchte. Es ist wie mit MS: Weils läuft, schimpfen nur ein paar, aber so richtig toll finden tuts keiner.
Zum "zusammengefassten" Format:
Zuerst kommen die Informationen zu den einzelnen Karten, denen aufsteigende Nummern verliehen werden. (Eigentlich hex, aber es scheint MORK egal zu sein, wenn man auch nur Dezimalzahlen verwendet. MORK ist tollerant!)
Und oh Wunder! Die kryptischen Einleitungen und Schlüsse sind verschwunden. Vielleicht ist der liebe Zauberer gekommen oder der böse Drache. Hauptsache, sie sind weg und stören nicht mehr. Mein böser Verdacht ist aber vielmehr, dass es sie gar nicht wirklich braucht, wenn man sie weglassen kann, und sie nur dazu dienen irgendwelche geheimnisvollen Gelüste des bösen MORK zu befriedigen..
(Ich habe nur Mailadressen gespeichert, natürlich könntest du auch Vornamen speichern usw. Die Zahlen werden dann einfach immer grösser und nie dürfen zwei den selben Schlüssel haben, sonst ignoriert MORK den Rest oder wird unlesbar.)
Nach den Informationen wieder eine lustige Einleitung mit Klammern auf, Klammern zu, mir schleierhaften Zuweisungen und bestimmt ganz wichtigen Informationen drin.
Und jetzt das beste: Zu jeder Karte ein vollständiger Block mit allen Schlüssel-Schlüssel-Zuweisungen wie im Beispiel mit nur 1 Karte. Weil du's begriffen hast nur die erste Karte.
Code: (dl
)
1
2
3
4
5
6
[1(^83=)(^84=)(^85=)(^86=)(^87=)(^88=)(^89^82)(^8A^82)(^8B=)(^8C=)
(^8D=)(^8E=0)(^8F=)(^90=)(^91=)(^92=)(^93=)(^94=)(^95=)(^96=)(^97=)
(^98=)(^99=)(^9A=)(^9B=)(^9C=)(^9D=)(^9E=)(^9F=)(^A0=)(^A1=)(^A2=)
(^A3=)(^A4=)(^A5=)(^A6=)(^A7=)(^A8=)(^A9=)(^AA=)(^AB=)(^AC=)(^AD=)
(^AE=)(^AF=)(^B0=)(^B1=)(^B2=)(^B3=)(^B4=)(^B5=)(^B6=)(^B7=)(^B8=)
(^B9=)(^BA=0)(^BB=1)]
Spannend ist die viertletzte Zuweisung auf der ersten Linie:
Code: (dl
)
(^89^82)
Sie sagt: "89 aus Block 1 (=Primary Email) gehört zu 82 aus Block 2 (=hallo@bello.ch). Schlicht göttlich.
Der letzte Eintrag "(^BB=1)" scheint zu sagen, dass wir uns in der ersten Karte befinden, was wir aber schon längst wissen, denn schliesslich beginnt alles mit der Zahl 1 (Gleich nach der eckigen Klammer). Clevere werden bemerken, dass das Minus vor der 1 (aus der "Einzelspeicherung") verschwunden ist. Was auch hier den Schluss zulässt, dass es eigentlich unnötig war.
Auf jeden Fall.
Nun zur guten Nachricht: Auch wenn MORK bei grossen Adressbüchern immer nur einige Karten in der zusammengefassten Form speichert und einige zuunterst in der Einzelspeicherung, ist es möglich, alles in zusammengefasster Speicherung zu schreiben.
Wie schon erwähnt muss man auch nicht unbedingt hex-Schlüssel verwenden in den Informationen in Block 2.
Spiel doch mal ein wenig herum mit einer foreach-Schleife, die 5 oder 10 oder 100 Einträge mit zufälligen Mailadressen oder Vornamen oder usw. füllt.
Du musst lediglich daran denken, genau die richtige Anzahl Blöcke Schlüssel-Schlüssel-Zuweisungen (Block 3) zu haben. Die kryptische Einleitung kannst du einfach abschreiben.
So lange man nur "von aussen" ins Adressbuch schreibt, ist alles wunderbar. Mischt man aber das "Reinfummeln" mit ordentlichem Einfügen via TB-Adressbuch-Verwaltung, gibt es ein göttliches, unlesbares Durcheinander, weil TB natürlich immer wieder zur gemischten Speicherung zurückkehrt.
Für mich war es spannend, zu "morksen" und es dient meinen Zwecken, von aussen (mit perl natürlich) ein lesbares Adressbuch zu schreiben. Interessant wäre es sicher, das Ganze so weiter zu entwickeln, dass volles Lesen und Schreiben möglich würde. Die Idee CPAN-Modul ist sicher grossartig. Wenn ich doch sehr hoffe, dass die Arbeit bald überflüssig wird, weil Mozilla zu einer vernünftigen (bekannten) Datenbank wechselt, für die bereits Anbindungen bestehen.
Zum Schluss ein paar Probleme & Fragen, die ich euch vorläufig gerne zum Weitertüfteln überlassen würde:
- Lösch mal eine Karte und schau, was MORK jetzt tut!
- Nach welcher Logik entscheidet er sich für eine der beiden Speicherungsarten?
- Welche Logik steckt hinter den Block-Einleitungen?
Wär mir ein Vergnügen, von euch zu lesen.
Vielleicht gründen wir sogar eine MORK-Community und treffen uns bald in einem tiefen, unheimlichen Zauberwald zum ersten MORKCOM-Treffen. An einem Freitag-dem-13., zu Vollmond und an Wintersonnwende, versteht sich.
GRMORKGRÜÜSSSSEEEE (Mit tiefer, lauter, gefährlicher Stimmer)
M.