Format von gespeicherten Dateien einer Anwendung...

[Amin Negm-Awad]

Da bist Du aber arg optimistisch. Die DTD schweigt sich über die Größe der Datentypen aus. Einfach darin herumändern kann ganz schnell eine Plist ergeben, die nicht mehr kompatibel zu einem Programm ist.

Dann ist wohl der Property-List-Scanner defekt.

Ja, ich hätte mir auch gewünscht, dass das definiert ist. De facto, aber eben nur de facto, was mir zu wenig ist, ist es definiert.

Aber es gibt freilich auch kein Verbot der Selbstdefinition. Wenn man sich sein Dateiformat ausdenkt und für den Export Property-Lists bedient, hält einen niemand davon ab, selbst zu sagen, dass dieser oder jener Wert eben folgenden Wertebereich hat. Man hat das wohl nicht in die DTD gepackt, weil es ja applikationsabhängig ist. (Was hilft dir die Erkenntnis, dass in einer Property-List 32-signed gespeichert werden können, wenn deine Applikation da einen Enum mit 5 Mitgliedern verlangt?)

Für Third-Party-Editoren gilt das freilich nicht, wobei die dasselbe Framework zur Erzeugung benutzen. Exakt ist also die Definition (exakt ist eigentlich das falsche Wort, vollständig träfe es besser) nicht, tatsächlich taucht dieses Problem jedoch nicht auf.

 

[Peter Maurer]

Skeeve, liest Du noch mit? Ich find' die Diskussion naemlich sehr interessant und habe Frage:

Ich bin den lieben langen Tag damit beschaeftigt, PLIST-formatige Daten hin- und herzuschieben (zwecks Persistenz und auch zwischen Prozessen via NSDistributedNotification zum Beispiel); und ich verstehe noch nicht ganz, warum PLISTs die Kommunikation zwischen Prozessen schwierig machen. Ich finde sie naemlich genau zu diesem Zweck unglaublich praktisch.

Bezieht sich Deine These insbesondere auf die Zusammenarbeit zwischen verschiedenen Betriebssystemen? Oder meinst Du, es sei mit dem Dir vorschwebenden XML leichter, einen veraenderten Datensatz zu verkraften, als speziell mit einer PLIST? (Falls letzteres: warum?)

--

Und zu Zettts Frage unterschreibe ich mehr oder weniger bei tjp: Wenn's eine Standardloesung fuer mehrere Dozenten werden soll, dann wuerde ich nicht mit Cocoa rumfuhrwerken (Haben die etwa alle Macs?), sondern eher was plattformunabhaengiges, u.U. auch gleich Web-basiertes ins Auge fassen.

 

[Skeeve]

Skeeve, liest Du noch mit?

Eigentlich nicht. Aber für Dich mache ich eine Ausnahme.

Ich find' die Diskussion naemlich sehr interessant und habe Frage:

Ich bin den lieben langen Tag damit beschaeftigt, PLIST-formatige Daten hin- und herzuschieben (zwecks Persistenz und auch zwischen Prozessen via NSDistributedNotification zum Beispiel); und ich verstehe noch nicht ganz, warum PLISTs die Kommunikation zwischen Prozessen schwierig machen. Ich finde sie naemlich genau zu diesem Zweck unglaublich praktisch.

Bezieht sich Deine These insbesondere auf die Zusammenarbeit zwischen verschiedenen Betriebssystemen? Oder meinst Du, es sei mit dem Dir vorschwebenden XML leichter, einen veraenderten Datensatz zu verkraften, als speziell mit einer PLIST? (Falls letzteres: warum?)

Offensichtlich habe ich mich wirklich undeutlich ausgedrückt.

Wenn man einfach die plists nimmt, dann ist das sehr bequem und auch okay, wenn man alleine damit arbeitet.

Wenn man hingegen mit "Unbekannten" Daten darüber austauscht, halte ich es für deutlich sinnvoller, ein Format zu definieren in dem die Daten geschrieben werden und sich an dieses Format zu halten.

Wenn ich plists richtig verstehe (und das tue ich wohl nicht) dann sind die im Prinzip nur ein "Speicherabzug" der Daten mit denen das Programm arbeitet. Wenn dem wirklich so ist, dann muß man, spätestens dann, wenn man seine Datenstruktur ändert, einen Konverter zwischen internem und externem Format erstellen, vorausgesetzt man will die Programme der "Unbekannten" nicht "zerstören". Warum also nicht direkt ein Format definieren?

Was mich weiterhin stört ist, daß in plisten ein <key> Element auftaucht, dessen Daten festlegen, was da kommt. Also werden Daten und Strukturinformationen vermischt.

Was auch noch unschön ist, ist der Vermischung zwischen "Variablentyp" und "Variableninhalt":
<key>Name</key><string>wert</string>
<key>Name</key><integer>wert</integer>
Soweit ja noch verständlich und nachvollziehbar. <key> legt den Namen fest, anschließend folgt ein Element, das den Typ definiert und darin steht der Wert.

Aber warum dann nicht:
<key>Name</key><boolean>wert</boolean>
sondern
<key>Name</key><true/>
<key>Name</key><false/>
inkonsequent!
Hier ist true/false der Wert und der Typ ergibt sich daraus dann als Boolean.

Frage ist auch warum <dict>s nicht hierarchisch sind. Ich empfinde es als unlogisch, wenn ich einen Eintrag suche, anschließend aufs Folgeelement zugreifen zu müssen. Mir fehlt einfach eine sinnvolle Hierarchie (mal wieder auf iTunes bezogen) die den logischen Aufbau wiederspiegelt. Amin hat das zwar alles schön begründet, warum das so ist, ich bezweifle die Gründe aber stark und behaupte frechweg, daß der einzige Grund Faulheit ist; "plist" existiert, "plist" verwendet XML format. Also schreiben wir für den export einfach 'ne plist.

Um zu plisten allgemein zurück zu kommen; Auch wenn Amin es als unlogisch bezeichnet, ich hätter eher was in der Art erwartet:
<string name="name">wert</string>

Aber gut... Die Meinung beruht auf meinen Erfahrungen mit "echten" XML Dateien und nicht mit "mißbrauchten" (nur meine unmaßgebliche Meinung).

 

[Peter Maurer]

Wenn man hingegen mit "Unbekannten" Daten darüber austauscht, halte ich es für deutlich sinnvoller, ein Format zu definieren in dem die Daten geschrieben werden und sich an dieses Format zu halten.

Nun koennte man das schlicht als PLIST definieren -- die sind schliesslich sehr ueberschaubar, weil sie nur ganz wenige Datentypen erlauben.

Wenn ich plists richtig verstehe (und das tue ich wohl nicht) dann sind die im Prinzip nur ein "Speicherabzug" der Daten mit denen das Programm arbeitet.

Ja, aber ...

Wenn dem wirklich so ist, dann muß man, spätestens dann, wenn man seine Datenstruktur ändert, einen Konverter zwischen internem und externem Format erstellen, vorausgesetzt man will die Programme der "Unbekannten" nicht "zerstören".

... da kommt die o.g. Ueberschaubarkeit ins Spiel: Sie repraesentieren nicht beliebige Datentypen, sondern nur bestimmte. Naemlich:

- Rohdaten (NSData)
- Zahlen (NSNumber)
- Zeichenketten (NSString)
- Arrays aus allen genannten Typen (NSArray)
- Dictionaries mit String-Keys und Values aus allen genannten Typen (NSDictionary)

Kann sein, dass ich eine Kleinigkeit vergessen habe, aber das war es im Wesentlichen. Und die in Klammern gegebenen Klassen sind bitte als Beispiele zu verstehen; tatsaechlich handelt es sich meist um verwandte, u.U. mutable Klassen.)

Das kann man jetzt unflexibel finden, und das ist wahrscheinlich auch das wahre PLIST-Problem (man verschiebt manche Codierungskonvention in die Umwandlung anderer Datentypen in einen der oben genannten -- aehnlich dem Witz, den Du weiter vorne gerissen hast), aber zu grosse Probleme durch Datenstruktur-Aenderungen sind m.E. nicht zu erwarten.

Was mich weiterhin stört ist, daß in plisten ein <key> Element auftaucht, dessen Daten festlegen, was da kommt. [...] Was auch noch unschön ist, ist der Vermischung zwischen "Variablentyp" und "Variableninhalt" [...]

Das wuerd' ich mal unter B-Note abheften. Man kann sich an der Form stoeren, ein echtes Hindernis ist das aber nicht, sondern nur eine Ansammlung von Konventionen, auf die man sich einigen muss.

Frage ist auch warum <dict>s nicht hierarchisch sind. Ich empfinde es als unlogisch, wenn ich einen Eintrag suche, anschließend aufs Folgeelement zugreifen zu müssen.

Ich finde das gerade logisch. Das <dict> ist, wie Du schon geschrieben hast, nichts weiter als eine NSDictionary-Abklatsch. Und NSDictionary hat keine hierarchischen "Kinder", sozusagen, sondern nur Schluessel und Werte. Wenn man fuer einen Key mehrere untergeordnete Eintraege ablegen will, dann setzt man als Value eben wieder ein Array oder Dictionary. Ungefaehr so (mehrere "Kinder"):

<dict>
	<key>Name</key>
	<string>Mutter</string>
	<key>Kinder</key>
	<array>
		<dict>
			<key>Name</key>
			<string>Tochter</string>
		</dict>
		<dict>
			<key>Name</key>
			<string>Sohn</string>
		</dict>
	</array>
</dict>

Ich find' das ziemlich ordentlich. Aber vielleicht hab' ich mich auch nur schon lange genug daran gewoehnt.

Auch wenn Amin es als unlogisch bezeichnet, ich hätter eher was in der Art erwartet:
<string name="name">wert</string>

Dass es so nicht geschrieben wird, ergibt sich m.E. direkt aus der schon besprochenen Verwandtschaft zwischen PLISTs und den zugrundeliegenden Datentypen. In Cocoa-Programmen gibt es nun mal keine Strings, die einen bestimmten Namen haben, sondern ein String ist ein String -- nichts weiter. Er wird u.U. von einem Dictionary als Key verwendet, was dann die Illusion hervorrufen kann, er habe einen Namen.

Jedenfalls bezeichnet Dein Beispiel fuer mein Gefuehl eher ein Dictionary (Key: "name"; Value: "wert") als einen String, deshalb wuerde es mir Magenschmerzen bereiten, das in der XML- oder PLIST-Datei einfach als "String" mit Attribut abzulegen.

 

[below]

Plists sind einfach recht flexibel, da ich mit einer DTD arbeiten kann.

Für den Ansatz von Skeeve muss man für jedes Dokument eine eigene DTD erstellen. Hat auch seine Vorteile, muss man aber nicht machen. tjp hatte mit seinem Einwand natürlich recht, dass ich auch bei Plists möglicherweise ungültige Daten reinschreiben kann.

Und auch Plists kann man mit XQuery bearbeiten.

Ich finde Plists ganz OK, aber wie bei allem was man macht: Kommt immer auf den Verwendungszweck an. Für platformübergreifenden Austauch ist wahrscheinlich ein Format mit eigener DTD am besten.

Alex

Alex

 

[Amin Negm-Awad]

Ich habe es in der Tat begründet. Deshalb verstehe ich deine Zweifel nicht, zumal du die Begründung verschweigst. Aber noch einmal, warum deine Zweifel ganz bestimmt unberechtigt sind: Nichts und niemand hindert mich daran in Property-Lists verschiedene Entitäten anzulegen. Die "platte" Datenstruktur, die iTunes expoertiert hat daher ganz, ganz, ganz gewiss nichts mit Property-Lists zu tun.

Übrigens hast du Property-Lists nicht verstanden: Sie sind von der Darstellung der Daten in der Applikation unabhängig. Du kannst auch intern Property-Lists verwenden. Sie sind etwa Bindings-compliant. Du kannst es auch lassen. In dem Client für meine Seite ist etwa der Text zur Laufzeit ein attributed String und persistiert als Property-List. Überhaupt gibt es nur eine handvoll Property-List-Objekte. Nicht jeder Applikation wird das offenkundig reichen.

+++

Es legt auch nicht der Key-Eintrag fest, welche Daten da kommen. Das legt der Value-Eintrag fest. Es heißt nicht

<key>haustürschlüssel<integer>5</integer</key>

Es heißt

<key>haustürschlüssel</key> <------ hiermit beendet
<integer>5</integer> <------- Neues Element

Und das ist auch richtig. Der Wert ist nämlich nicht der Wert zu einer Entität key. Es handelt sich hierbei um ein Dictionary. Dictionarys sind Schlüssel-Werte-Paare, *nicht* Entitäts-Attributs-Beziehungen. So etwas wie

<haustürschlüssel>5</haustürschlüssel>

zu verlangen, ist daher für ein Dictionary schlichtweg falsch. Schlüssel und Wert sind gleichberechtigt und bilden ein Paar, keine Hierarchie. Niemand käme auf den Gedanken, so etwas zu machen:

<rechterSchuh>linkerSchuh</rechterSchuh>

Bloß weil jeder rechte Schuh einen linken haben muss. Denn Schuhe bilden Paare, nicht Hierarchien. Dictionarys bilden ebenfalls Paare, sie bilden ebenfalls keine Hierarchien.

Aber ich schreibe dazu ja ein Tutorial …

 

[Zettt]

(Haben die etwa alle Macs?)

Ja haben sie --- und selbst wenn nicht stehen bei uns im Haus genuegend rum. (Ansage vom Chef: Ab jetzt gibt's nur noch Macs) :-D

Aber ich faende auch eine andere Loesung (webbasiert) grundsaetzlich auch ganz cool.
Ueber Bindings waeren manche Dinge halt sehr schnell realisierbar.

Webbasiert ist super. Unsere Studentenverwaltung funktioniert online und somit kann im Prinzip Cheffe von Dubai die Daten genauso bequem einsehen wie fuer Stuttgart.
Ich selbst hab nur noch nie etwas mit MySQL gemacht. Gut ich koennte den Webdesign Kollegen mal anhauen...aber der Stolz, der Stolz...

 

[Amin Negm-Awad]

Ja haben sie --- und selbst wenn nicht stehen bei uns im Haus genuegend rum. (Ansage vom Chef: Ab jetzt gibt's nur noch Macs) :-D

Aber ich faende auch eine andere Loesung (webbasiert) grundsaetzlich auch ganz cool.
Ueber Bindings waeren manche Dinge halt sehr schnell realisierbar.

Webbasiert ist super. Unsere Studentenverwaltung funktioniert online und somit kann im Prinzip Cheffe von Dubai die Daten genauso bequem einsehen wie fuer Stuttgart.
Ich selbst hab nur noch nie etwas mit MySQL gemacht. Gut ich koennte den Webdesign Kollegen mal anhauen...aber der Stolz, der Stolz...

NIEMALS DIE WEBBIES FRAGEN! Das ist ja PEINLICH!

 

[Zettt]

Ich hab ja schon unser MySQL Buch aufgeschlagen _ø_(.. ) :-[

 

[Skeeve]

Plists sind einfach recht flexibel, da ich mit einer DTD arbeiten kann.

1. XML Dateien können auch mit einer DTD arbeiten -> Also auch flexibel
2. Was nutzt Dir die DTD der plist?

Für den Ansatz von Skeeve muss man für jedes Dokument eine eigene DTD erstellen.

1. Nein! Für jeden DOCTYPE! NICHT für jedes DOKUMENT
2. Nein! Man MUSS nicht!
   Mann kann und es hat Vorteile

Hat auch seine Vorteile, muss man aber nicht machen. tjp hatte mit seinem Einwand natürlich recht, dass ich auch bei Plists möglicherweise ungültige Daten reinschreiben kann.

Nicht nur das! Wenn Du eine plist schreibst und ein Scherzkeks (ich) hingeht und die "iTunes Music Library.xml" stattdessen an die Stelle kopiere, dann rate mal, was Dir die DTD nutzt. Null und Nix! Wenn Du die Datei per DTD verifizierst, ist die 100% in Ordnung. Aber dein Programm wird höchstwahrscheinlich herzlich wenig damit anfangen können. Und das "Schöne" ist, Dein Programm merkt es nicht! Es sieht den passenden DOCTYPE, es findet das passende Wurzelelement -> Heile Welt! Ja vonwegen. Hättest Du einen eigenen DOCTYPE und eine passende DTD, würde Dir schon beim Parsen jeglicher Fehler (der per DTD abfangbar ist) gemeldet.

Und auch Plists kann man mit XQuery bearbeiten.[/LIST]
Klar kann man. Man kann sich auch einer Wurzelbehandlung unterziehen oder einen Einlauf verpassen lassen. Aber es gibt deutlich Angenehmeres.

Ich finde Plists ganz OK, aber wie bei allem was man macht: Kommt immer auf den Verwendungszweck an. Für platformübergreifenden Austauch ist wahrscheinlich ein Format mit eigener DTD am besten.

Hier stimme ich Dir 100% zu! Mit der Eiweiterung: Auch für Anwendungsübergreifenden Austausch ist eine igene DTD (oder Schema) deutlich besser.

 

[below]

1. 
   Nein! Man MUSS nicht!
   

   Und auch Plists kann man mit XQuery bearbeiten.

   Klar kann man. Man kann sich auch einer Wurzelbehandlung unterziehen oder einen Einlauf verpassen lassen. Aber es gibt deutlich Angenehmeres.

1. 
   
   * Wenn Du aber keine eigene DTD erstellst, dann ist Dein eigenes Format genau so "unbrauchbar" wie eine Plist
   
   * Naja, ich mag XQuery deshalb, weil es eben mit jedem Format klarkommt. Und "merkwürdige Dokumente" hat nicht nur iTunes.
   
   Alex

 

[Skeeve]

* Wenn Du aber keine eigene DTD erstellst, dann ist Dein eigenes Format genau so "unbrauchbar" wie eine Plist

Genau! 100% Zustimmung.

* Naja, ich mag XQuery deshalb, weil es eben mit jedem Format klarkommt. Und "merkwürdige Dokumente" hat nicht nur iTunes.

Es geht mir weniger um XQUERY als um den Aufwand, den Du treiben mußt, um etwas zu filtern in (z.B.) dem iTunes XML verglichen zu dem, was ich als Unmaßgeblicher, als logischer erachte.

 

[osfreak]

Hmmmm, das Format (Property-Lists) ist sicherlich so allgemein, dass man es auf jeder Plattform lesen kann. Mutmaßlich meinst du, dass es nicht für jede Programmiersprache einen vorgefertigten Scanner gibt.

Nein ich meine das nicht bezogen auf die Programmiersprache sondern auf das Betriebssystem. Nur MacOS kennt das Package-Konzept und kennt dafür eine Spezifikation für die Property-Lists.

Sicherlich kann man solche Property lists prinzipiell woanders auch lesen oder wer mag kann sich selber Programme dazu schreiben aber ich sehe da insgesamt noch keine ernsthafte Plattformunabhängigkeit. Sonst wäre ja beispielsweise die Windows-Registry auch plattformunabhängig denn die kann man ja auch überallhin kopieren und drumherum Programme schreiben.

Und Scanner wären nun auch nicht an die Programmiersprache gebunden sondern an die System-API bzw. die Entwicklungsumgebung. Ich weiß jedenfalls keine Programmiersprache, die einen Property-List-Scanner definiert. Das sind alles Funktionen aus der MacOSX-API.

Thomas

 

[Amin Negm-Awad]

Nein ich meine das nicht bezogen auf die Programmiersprache sondern auf das Betriebssystem. Nur MacOS kennt das Package-Konzept und kennt dafür eine Spezifikation für die Property-Lists.

Was hat denn eine Property-List mit dem Package Konzept zu tun? Eine Property-List st eine *beliebige* Ansammlung von Daten. Das hat nichts damit zu tun, ob sie gerade dazu dient, ein Package zu beschreiben, launchd zu konfigurieren oder eine Titelliste aus iTunes zu exportieren.

Property-Lists verhalten sich in etwa zu Packages so wie Objective-C zu Damenunterwäsche.

Sicherlich kann man solche Property lists prinzipiell woanders auch lesen oder wer mag kann sich selber Programme dazu schreiben aber ich sehe da insgesamt noch keine ernsthafte Plattformunabhängigkeit. Sonst wäre ja beispielsweise die Windows-Registry auch plattformunabhängig denn die kann man ja auch überallhin kopieren und drumherum Programme schreiben.

Die Windows-Registry dient dazu, Windows zu "konfigurieren". Property-Lists dienen dazu irgendwelche, beliebigen, völlig frei wählbaren Daten zu verwalten. Ich mutmaße, dass du auch das plain Text Format nur für Unix für sinnvoll erachtest, weil man dort damit Programme konfiguriert? Oder JPEG nur für Photos im Adressbuch, weil man sie dort verwenden kann?

Und Scanner wären nun auch nicht an die Programmiersprache gebunden sondern an die System-API bzw. die Entwicklungsumgebung. Ich weiß jedenfalls keine Programmiersprache, die einen Property-List-Scanner definiert. Das sind alles Funktionen aus der MacOSX-API.

????????????
Ich hatte geschrieben, dass ich mir einen Scanner in PHP geschrieben hatte.

Der Server fährt übrigens Linux. Gespeichert werden Texte. Ich kann nicht verstehen, was du damit sagen willst?

Ich finde jedenfalls ein Format, für das man Dateien leicht in Objective-C/Cocoa unter OS X erzeugen kann, um diese dann leicht mit PHP unter Linux lesen zu können, ziemich plattformunabhängig.

Es kann aber auch einfach sein, dass du Format mit Einsatzzweck verwechselst und dabei Einsatzzweck von dir mit dir gerade bekannten Einsatzzwecken gleichsetzt.

 

[below]

Nein ich meine das nicht bezogen auf die Programmiersprache sondern auf das Betriebssystem. Nur MacOS kennt das Package-Konzept und kennt dafür eine Spezifikation für die Property-Lists.

Das ist ja interessant.

Du solltest Apple schreiben, dass sie auf ihren Seiten Fehler haben:
"In this article, we start by describing the kind of environment you need to build CF-Lite on Mac OS X, Darwin, Linux and even Windows (via Cygwin). Next, we walk you through the basics of CF-Lite, including a simple application for reading and displaying property lists."
http://developer.apple.com/opensource/cflite.html

Alex