🚀 go-pugleaf

Thomas Engel <tomi@shinto.nbg.sub.org> wrote:

> Nun das hat alles zwei Seiten. Die L�sung des Mac ist sicherlich die 
> elegantere...aber wenn man dann Dateien erst immer durch den BunchTyper jagen
> mu� um sie dann mit machen Programmen zu �ffnen oder diverse Umwege 
> einschalgen mu� wenn man will, das bestimmte Dateitypen immer mit einer
> bestimmten Applikation ge�ffnet werden sollen dann ist das auch noch nicht
> das gelbe vom Ei.

Wenn's nur darum geht, Dokumente "ausnahmsweise" mit einem anderen
Programme als mit dem in ihrem Creator Code zu �ffnen, so mu� man dies
halt explizit aus dem entsprechenden Programm heraus tun oder die
Dokumente auf das entsprechende Programm droppen. F�r dauerhaftes
"Ummappen" gibt's z.B. in SpeedyFinder und ggfs. direkt in neueren
MacOS-Versionen M�glichkeiten (w�re zumindest einfach zu
implementieren).
Wenn's darum geht, einem Suffix einen File Type zuzuordnen, so tritt
dieses Problem ja nur beim "Importieren" von Dateien "von au�en" auf.
Das entsprechende Programm/Systembestandteil mu� diese Zuordnung dann on
the Fly (konfigurierbar) vornehmen, was auch in vielen F�llen heute
bereits geschieht und gut funktioniert:
bei HTTP wird sowieso der MIME-Typ �bermittelt, Browser k�nnen leicht
eine entsprechende Abbildung auf File Types vornehmen und machen dies
bereits heute so. Bei ftp bzw. beim Importieren via DOSen-Diskette
machen es z.B. Fetch bzw. PC Exchange an Hand des Suffixes des
Dateinamens beteits seit langem so.
> 
> NeXTs L�sung ist sicherlich nicht toll. Alles was mit Dateilendungen arbeitet
> ist etwas schwach. Jedoch hat NeXT ein L�sung die an sich zumindest recht
> einleuchtend ist.

Es ist *nicht* einleuchtend, warum der *Dateityp* Teil des *Dateinamens*
sein mu�. Das handelt sich um vollkommen unterschiedliche Attribute
einer Datei. Es ist vollkommen unnat�rlich, eine Datei statt z.B.
"Anleitung f�r Kaffeemaschine" anleitung_kaffeemaschine.txt nennen zu
m�ssen. Es hat sich auf vielen Systemen deshalb so eingeb�rgert, weil es
dort keine M�glichkeit der expliziten Angabe des Dateityps gibt (soda�
es heute viele Leute schon wieder als vollkommen nat�rlich empfinden
:-)). HTTP als ein modernes �bertragungsprotokoll z.B. hingegen
beinhaltet explizit die �bertragung des Dokumenttyps unabh�ngig vom
Dateinamen (genauer gesagt von der "Pfadkomponente" der URL).

> Wenn man generell mit einer Art Systemweitem "MIME-Type" Mapping arbeiten
> w�rde und je nach Dateisystem einfach nur das richtige passieren 
> wuerde...ja...sowas sollte es haben.
MIME-Types und Apples File Types sind ja vom Konzept her dasselbe.

> Aber nicht in der doofen Art wie das bei Win95 passiert....dort hat der
> MIME-Type ja eigentlich keinen echten Sinn (zumindest konnte ich noch keinen
> entdecken)
mag sein. Wen st�rt's? Was ist eigentlich �berhaupt Win95? :-)

> 
> NeXTs(Apples) DOS Dateisystem sollte jedoch in Zukunft auch das Win95 Format
DOS??? Was hat den das hier zu suchen???

> mit langen Namen unterst�tzen, da man ansonsten wieder ein paar 
> Schwierigkeiten hat den Leuten die Migration von Win95 nach "MacStep"
> schmackhaft zu machen.

sicherlich schadet es nicht, wenn man z.B. Konvertiertools f�r Disketten
entwickelt (gibt's vermutlich bereits), aber mehr ist ja nun wirklich
nicht notwendig. Besser w�re da schon eingebauter NFS-Support.
-- 
Georg Schwarz     schwarz@physik.tu-berlin.de, kuroi@cs.tu-berlin.de
Institut f�r Theoretische Physik       +49 30 314-24254, FAX -21130
Technische Universit�t Berlin        http://home.pages.de/~schwarz/