Das mit denn Bookmarks in einer SQL Datenbank klingt doch gut. Vllt. wird das endlich eine ordentliche Lösung zum zentralen Verwalten der Bookmarks sein. Bin mal gespannt.
Genau über den Punkt musste ich auch nachdenken. Allerdings mit umgekehrtem Vorzeichen. Ich befürchte, dass durch das Speichern in sqllite ein zentrales Verwalten von Bookmarks in noch weitere Ferne rückt.
Beim weiteren Nachdenken ist das natürlich quatsch. Es ist ja vollkommen egal, wie und wo die Bookmarks gespeichert werden, man muss nur einen Standard etablieren, an den sich alle Bookmarks verwendende Applikationen halten. Ich hätte aber eher an LDAP oder ähnliches gedacht. Dort könnte man dann auch zentral alle Adressen und Kalenderdaten speichern.
Bin mal gespannt, ob da irgendwann mal eine Lösung für kommt. Da ich häufig die Browser wechsel, um weder KDE noch Gnome zu vernachlässigen ;), finde ich es sehr wichtig, einen Bookmark-Standard zu haben, der überall benutzt wird. Ggf. könnte man die Datenquelle dann ja auch remote verwenden, ohne seine persönlichen Daten in die Hand eines Bookmark-Verwaltungsservice im Internet anzuvertrauen.
Als kleine Anregung vielleicht dieses Projekt hier: http://sitebar.sourceforge.net Dafür gibts auch ein Firefox-Plugin: https://addons.mozilla.org/extensions/moreinfo.php?id=1545&application=firefox
Plugins für andere Browser kenne ich jetzt nicht. In den Navigationsbereich des Konqueror lässt es soch noch mittelprächtig integrieren. Allerdings nicht ganz so gut wie in den Firefox. Letzten endes sind die gesammelten Bookmarks aber auch nur über eine Website bereit gestellt, die man mit jedem Browser besuchen kann.
Der Ansatz ist nicht schlecht. Wenn man selber den Server (bspw. auf dem lokalen Rechner) dafür betreibt ist es auch vom Datenschutz her ok. Allerdings ist der Aufwand dafür ja doch ziemlich hoch. Außerdem dürfte die Integration in den Browser, was das Pflegen der Bookmarks angeht, deutlich unkomfortabler sein, oder?
Wie ich gerade sehe, ist die grundlegende Installation ja sogar mit "apt-get update sitebar" in debian/sid möglich.
> Außerdem dürfte die Integration in den Browser, > was das Pflegen der Bookmarks angeht, deutlich > unkomfortabler sein, oder? Nunja.. das Pflegen ohne das Firefox-Plugin ist dann echt nicht sonderlich benutzerfreundlich, was halt an der Natur dieser Browserbezogenen Skripte liegt. Man muss auf eine Einfügenseite der Sitebar gehen, um dann dort die Daten für den neuen Bookmark auszufüllen. Doch das Plugin für den Firefox macht die Sache dann schon wieder interessanter. Bist Du auf einer Page, die Du bookmarken willst, brauchst du nur die rechte Maustaste drücken und wählst den Eintrag 'Add to SiteBar' aus. Daraufhin öffnet sich ein Fenster, bei dem Du den Ordner angibst, wo der Link gespeichert werden soll. Die url und die Beschreibung der Page ist bereits vorausgefüllt. Das macht die Sache eigentlich genauso einfach wie bei den Broserintegrierten Lesezeichen. Sitebar ermöglicht obendrein das Importieren und Exportieren von Lesezeichen für die verschiedensten Formate (XBEL, Netscape, Opera, etc).
Von PERL-Gott Michael Schilli gab es da mal einen netten Artikel im LinuxMag. Ist ein cgi, das die BM Verwaltung übernimmt, hinzufügen kann man via JS konfortabel aus jedem Browser ohne zusätzliche Plugins. Datenschutz ist mit einem per SSL gesichertem Webserver auch möglich. Lediglich die Verwaltung (verschieben, ordnen) ist etwas rudimentär, aber das Script kann man ja nach Belieben ausbauen.
Wichtig sind im Grunde lediglich zwei Dinge. Eine abstrahierte Verwaltungs-API die möglichst nah an XBEL orientiert ist und deren Backend man dann nach Wunsch wechseln kann. Dann kommen die LDAP-Extensions schon von ganz allein. Ich weiß allerdings nicht, ob/wie Firefox das jetzt nun in der Tat umsetzt mit seinem SQLite-Backend.
Was genau soll an einer SQL-Datenbank besser sein als an Bookmarks im etablierten HTML-Format? So können die Bookmarks zumindest mit jedem anderen Browser angeschaut oder auch importiert werden und sie sind zur Not auch mit einem ASCII-Editor bearbeitbar.
Alles, was dies verunmöglicht, ist unbrauchbar.
Das Strukturieren der Links wird einem dadurch auch nicht abgenommen.
> Das Strukturieren der Links wird einem dadurch auch nicht abgenommen. Das nicht, aber man könnte mehr Möglichkeiten zum Strukturieren bekommen ohne in Wartungsprobleme zu stolpern, also z.B. Lesezeichen zu Artikeln geordnet nach mehreren Kategorien:
Thema des Artikels
Autor
Veranstaltung bei der er vorgestellt werden soll
ändert sich nun eine URL, so muss man sie nur einmal anpassen und nicht für jede Kategorie einzeln.
> Was genau soll an einer SQL-Datenbank besser sein als an > Bookmarks im etablierten HTML-Format?
Steht doch alles da: Performance und Stabilität.
> So können die Bookmarks zumindest mit jedem anderen Browser > angeschaut oder auch importiert werden und sie sind zur Not > auch mit einem ASCII-Editor bearbeitbar.
In einem ASCII-Editor brauchen sie nicht bearbeitbar zu sein, weil es sich um Browser-Bookmarks handelt - deswegen bearbeitet man sie im Browser - und zur Benutzung in anderen Browsern gibt es eine Exportfunktionalität.
> Alles, was dies verunmöglicht, ist unbrauchbar.
Nein, natürlich nicht. Man bekommt zwar im Linux-Umfeld immer wieder eingetrichtert, alles, was nicht ASCII ist, sei unbrauchbar, dadurch wird es aber noch lange nicht richtig.
SQLite wird auch in vielen anderen Projekten benutzt und ist dementsprechend getestet und außerdem wird das Places-Feature Dinge miteinander verknüpfen, sie sich gar nicht mehr in standardkonformem HTML abbilden lassen.
>> Was genau soll an einer SQL-Datenbank besser sein als an >> Bookmarks im etablierten HTML-Format? > >Steht doch alles da: Performance und Stabilität.
Schon möglich. Aber seit wann brauchen bookmarks performance?
>> So können die Bookmarks zumindest mit jedem anderen Browser >> angeschaut oder auch importiert werden und sie sind zur Not >> auch mit einem ASCII-Editor bearbeitbar. > >In einem ASCII-Editor brauchen sie nicht bearbeitbar zu sein, weil es sich um Browser-Bookmarks >handelt - deswegen bearbeitet man sie im Browser - und zur Benutzung in anderen Browsern gibt es eine >Exportfunktionalität.
Wie er schon sagte: "... zur Not ...". Was machst du mit einer Datenbank wenn sie einmal beschädigt ist? Ich kenne SQLite nicht, aber ein html file kann ich ohne Probleme selbst wieder hinbiegen.
>> Alles, was dies verunmöglicht, ist unbrauchbar. > >Nein, natürlich nicht. Man bekommt zwar im Linux-Umfeld immer wieder eingetrichtert, alles, was nicht >ASCII ist, sei unbrauchbar, dadurch wird es aber noch lange nicht richtig.
ASCII files haben aber eben den grossen Vorteil, das sie von normalen Menschen einfach selbst bearbeitet werden können.
Was machst du mit einer Datenbank wenn sie einmal beschädigt ist? Ich kenne SQLite nicht, aber ein html file kann ich ohne Probleme selbst wieder hinbiegen.
In einer Datenbank kann man Inhalte über die vorgegebene SQL-Schnittstelle viel leichter verwalten als in einer Datei, für die man selber die Zugriffsroutinen schreiben muss. Das, was Du vermutlich mit einer zerschossenen bookmark.html Datei meinst, wird (hoffentlich) mit einer sql-Engine im Hintergrund viel seltener auftreten. Um umfangreich zerstörte Daten dann reparieren zu können braucht man dann eh ein Backup. Da ist es dann egal, ob das eine *.html oder eine *.sqllite Datei ist.
Allerdings kann ich selber auch verstehen, dass man zu einer ASCII-Datei erstmal größeres Vertrauen hat, da man selber einfacher und direkter (per normalem Editor) an die Daten rankommt.
>>Steht doch alles da: Performance und Stabilität. Performance? Bei Bookmarks? lach! Stabilität? Was genau ist bei HTML unstabil?
Um Daten auch nach Jahren noch bewirtschaften zu können, ist es erforderlich, diese in einem Format abzuspeichern, welches auch dann, wenn dieses Format nicht mehr bewirtschaftet wird, noch gelesen und bearbeitet werden kann.
>>In einem ASCII-Editor brauchen sie nicht bearbeitbar zu sein, weil es sich um Browser-Bookmarks handelt - deswegen bearbeitet man sie im Browser - und zur Benutzung in anderen Browsern gibt es eine Exportfunktionalität.
Das ist Nonsens. Exportfunktionalitäten verlangen definierte Schnittstellen. Wenn diese nicht vorhanden bzw. deren Definitionen nicht offengelegt sind, müssen die Daten bearbeitbar sein und zwar auch ausserhalb der benutzten Applikation, sonst sind sie proprietär formatiert und das wollen wir ja alle nicht, oder?
>>Nein, natürlich nicht. Man bekommt zwar im Linux-Umfeld immer wieder eingetrichtert, alles, was nicht ASCII ist, sei unbrauchbar, dadurch wird es aber noch lange nicht richtig.
Das ist ebensolcher Unsinn. Niemand sagt hier, dass alles, was nicht ASCII sei, unbrauchbar sei. ASCII ist ein für Texte, allenfalls auch Datenbanken geeignetes Format, welches aber auch etwelchen Einschränkungen unterliegt (Diakritische Zeichen, nicht-lateinische Schriften, neue Zeichen wie etc., wo oft auch der erweiterte ASCII-Zeichensatz nicht mehr ausreicht). Für Bookmarks würde er allerdings vollauf genügen. ;-)
Dass SQLite auch in anderen Projekten benutzt wird, macht es nicht schlechter oder besser - es ist für solche Projekte möglicherweise einfach besser geeignet.
Im übrigen wäre zu diskutieren, ob nicht statt eines grundsätzlichen Format-wechsels einfach zu XML gewechselt werden soll, welches weit höheren Anforderungen gerecht wird als selbst HTML 4.
"Erst Firefox 3, das nach dem Willen der Entwickler bereits ein halbes Jahr nach Firefox 2 fertig sein soll, soll Gecko 1.9 einsetzen. Diese Version wird grundlegende Neuerungen bringen, da die Grafikausgabe der Bibliothek Cairo überlassen wird."
Echt, warum dann das nächte Release 2 nennen und nicht 1.6? Warum dann schon 2, wenn grundlegende Neuerungen erst im dreier Release vorgenommen werden. Vielleicht verstehst Du nun, was ich meinte.
Prinzipiell bin ich Deiner Meinung. Ich finde es immer sehr positiv, wenn Entwickler mit ihrem Produkt nicht so sehr über die Versionsnnummer rumprollen, sondern ganz bescheiden die 0 vor dem Komma belassen, da das Programm noch Bugs enthält oder enthalten könnte.
Andererseits ist es aber doch vollkommen egal. Die Versionsnummer muss eindeutig sein. Ob die 2 oder 3 vor oder hinter dem Komma steht, die Nummer sollte nur streng monoton steigen. Aber es ist schön, dass es uns so gut geht, dass wir uns über so Kleinigkeiten aufregen können.
Du hast ja im Prinzip auch recht und vermutlich stößen sich die meisten Unix-Nutzer damit. Aber Du darfst nicht vergessen, das der Firefox primär auf Windows abzielt und dort nur etwas verwendet wird, dass monatlich in 10er-Schritten bei der Versionierung weitergeht und man 2004 am besten schon Monster-Software 2090 verwenden möchte Dafür, dass der Firefox durchaus dazu beigeholfen hat, dass ich einige Leute von Windows losbekommen habe, lasse ich mir die Versionierung durchaus gefallen. Letztendlich dachte ich immer, dass der Unix-Anwender eher auf Funktionalität achtet als auf Namen und Versionen
Geplant war, dass die nächste Release von Firefox 1.5 die 2.0 sein wird mit der neuen Rendering-Engine Gecko 1.9. Aus welchen Gründen auch immer hat es doch nicht geklappt Gecko 1.9 in Firefox 2.0 aufzunehmen. Nun kommt Firefox 2.0 zwar rechtzeitig aber leider ohne Gecko 1.9 heraus. Den meisten Benutzern ist es egal was drin steckt, hauptsache die neue Version kommt rechtzeitig. Die Firefox-Version mit der neuen Rendering-Engine wird dann 3.0 sein.
Ich war gerade mit dem IE7 beta2 auf der Seite. Mal davon abgesehen, dass er noch hie und da hakt, rendert er sauschnell. Sieht so aus, als habe man sich wirklich angestrengt.
Ich scheiß persönlich drauf, wenn das Teil schnell rendert und dafür wieder nur MS-Varianten von HTML und CSS kann... Standards sollten die Damen und Herren aus Redmond mal unterstützen, auch wenn die nicht von ihnen entworfen wurden.
Machen wir doch gleich ein event daraus, einmal im jahr organisieren wir eine Reise nach Redmond und k***** ein paar mal Ordentlich an das Microsoft Hauptquartier!
Von Michael Lehmeier am Mi, 22. März 2006 um 19:45 #
Besteht eigentlich das Bestreben, den Firefox fit für den Smiley Test zu machen oder ignorieren sie das Problem einfach? Zumindest auf meiner 1.5 besteht er ihn immer noch nicht und das ist schon irgendwie... bedenklich.
Das ist allerdings höchst bedenklich - besonders, nachdem das sehrwahrscheinlich eine der ganz wenigen Seiten ist, die Firefox nicht einigermassen sauber darstellen kann.
Ein echtes Problem ist das sicher nicht - allerhöchstens eine programmiertechnische Herausforderung. 99.9% aller Firefox-Benutzer werden niemals mit solchen Problemen konfrontiert, wie sie beim Smiley-Test auftauchen.
Von Michael Lehmeier am Do, 23. März 2006 um 01:59 #
Das ist dabei relativ irrelevant, wie viele mit den Problemen in Berührung kommen werden. Das Problem ist, dass das Smiley absolut standardkonform ist und Firefox ihn nicht anzeigen kann. Das bedeutet, dass Firefox nicht standardkonfrom ist. Ich wollte wissen, ob es überhaupt auf dem Plan von Firefox steht, standardkonform zu werden.
Für mich ist das ein wichtiger Punkt. Gerade hier hatte ich früher einen wichtigen Vorteil von Mozilla gesehen und jetzt hat sogar Microsoft angekündigt, den Smiley-Test in absehbarer Zeit bestehen zu wollen. Da darf Firefox einfach nicht hinten an stehen.
>Das ist dabei relativ irrelevant, wie viele mit den Problemen in Berührung kommen werden. >Das Problem ist, dass das Smiley absolut standardkonform ist und Firefox ihn nicht anzeigen kann. Das >bedeutet, dass Firefox nicht standardkonfrom ist. >Ich wollte wissen, ob es überhaupt auf dem Plan von Firefox steht, standardkonform zu werden.
Im ACID Test befinden sich absichtlich Fehler um zu sehen wie verschiedene Browser darauf reagieren.
>Für mich ist das ein wichtiger Punkt. >Gerade hier hatte ich früher einen wichtigen Vorteil von Mozilla gesehen und jetzt hat sogar >Microsoft angekündigt, den Smiley-Test in absehbarer Zeit bestehen zu wollen. Da darf Firefox einfach >nicht hinten an stehen.
Meine letzte Info sagt was anderes. MS sagte, das auch die finale Version des IE den ACID Test nicht bestehen wird.
Im ACID Test befinden sich absichtlich Fehler um zu sehen wie verschiedene Browser darauf reagieren. Es ist im Standard genau festgelegt, wie ein Browser auf diese Fehler zu reagieren hat. Ein Browser, der den ACID-Test nicht besteht, ist also zumindest in Bezug auf die Fehlerbehandlung nicht standardkonform.
Wird die File, in der die Bookmarks dann gespeichert werden dann eine Binärdatei?? Das fände ich extrem g'schiss'n! Am besten finde ich ja da eine Lösung auf Basis von XML. Das lässt sich schön in einen Texteditor lesen/ändern und per XSLT in ein anderes Format konvertieren. Also wenn man der Browser/das OS im Arsch ist, kann ich trotzdem noch meine Bookmarks lesen. Ganz ohne Firefox, einfach mit nen Texteditor. Wird das dann nicht mehr gehn oder verwendet SQLite XML?
Ja, es wird eine Binärdatei, die du aber auch unabhängig von Firefox mit "sqlite bookmarks.db" lesen können wirst (sofern du SQL kannst), außerdem wird firefox die bookmarks ja noch exportieren können. Mal eben "schnell" mit XSLT deine Bookmarks zu konvertieren stelle ich mir dagegen, äh, wenig wünschenswert vor. (schauder). Und wenn Firefox XML verwenden würde (also wie bisher, html ist es ja schon lange nicht mehr), dann würdest du die ganzen Probleme, die es jetzt damit gibt, immer noch haben: keine atomaren updates, keine recovery bei fehlern, schlechtes skalieren. IMHO ist XML ein gutes Im/Exportformat aber nicht die ultima ratio beim Speichern von Anwendungsdaten (noch dazu, wenn sich diese bei der Benutzung der Anwendung dauernd ändern, mehrfach indiziert werden müssen und der Benutzer erwartet, dass sie die ganze Zeit auf der Platte aktualisiert werden).
... endlich mal die Werbeversprechen einzuhalten, besonders die, die da immer lauten "schnell" und "schlank". Und nein, ich möchte nicht, dass er noch schlanker im Funktionsumfang wird - was ja laut der heutigen offiziellen Wahrheit die Programme leichter benutzbar machen soll, sondern er soll schlanker im Speicherverbrauch werden. Mit der Version 1.5.0.1 hat sich die Situation durch ein paar beseitigte Memory-Leaks zwar leicht gebessert, aber der Effekt, dass der Firefox den Rechner nach ein paar Tagen Laufzeit unbenutzbar macht, weil er sich dann nämlich 70% und mehr des Speichers genehmigt (ca. das dreifache, was Galeon so für sich beansprucht), ist immernoch da.
Auch wäre es toll, wenn es mal wieder eine vernünftige Suchfunktion für die Bookmarks gäbe, eine, die nicht nur Titel-basiert suchen kann (was ja das idiotischste überhaupt ist), und die auch den/die Ordner ausgibt, in denen die Treffer liegen. Das wäre mal eine wirkliche Erleichterung. Und das traurige daran ist, dass das alles schon mal vorhanden war. Stattdessen muss man sich dann mit externen Tools mehr schlecht als recht behelfen.
Naja, nun ändern sie das Backend aufgrund irgendwelcher seltsamer neuer Visionen, zerschlagen damit die Kompatibilität zu dem altgedienten und recht einfach handhabbaren Format, und es sind immernoch nicht die grundlegenden Dinge erledigt.
Könnte es sein, dass du Webbrowser und Webserver verwechselst? Ich habe zumindest nicht den Anspruch, dass mein Browser mehr als 10 Stunden am Stück laufen muss und dürfte mich damit schon am oberen Ende der Benutzer befinden. Und schneller ist die 1.5 schon deutlich geworden, zumindest unter Linux. Da war die 1.0 bei mir zumindest sau lahm, während der 1.5 praktisch immer flüssig läuft, auch bei vielen komplexen Tabs.
Könnte es sein, dass du Webbrowser und Webserver verwechselst?
Nö. Um auch mal ne Unterstellungsfrage loszulassen: Kann es sein, dass Du mit Windows vielleicht ganz gut bedient wärst?
Ich habe zumindest nicht den Anspruch, dass mein Browser mehr als 10 Stunden am Stück laufen muss
Ich schon, und warum soll ich mich einschränken müssen, nur damit der Firefox immer der hochgelobte und über jeden Zweifel erhabene Brauser ist, nur weil einige Gelegenheitsnutzer geringere Ansprüche haben? Ich will meinen Brauser intensiv nutzen können, und wenn ichs mal nicht geschafft kriege, alle offenen Tabs abzuarbeiten, dann wird das eben auf die nächsten Tage verschoben. Wieso soll ich den Brauser beenden, wenn es gar nicht nötig ist? Außerdem klappt das ja mit anderen Brausern wunderbar, also warum sollte man nicht auch an den Firefox diese Ansprüche stellen dürfen?
Und schneller ist die 1.5 schon deutlich geworden, zumindest unter Linux. Da war die 1.0 bei mir zumindest sau lahm, während der 1.5 praktisch immer flüssig läuft, auch bei vielen komplexen Tabs.
Ja, da hat sich schon einiges getan, aber Raum für Verbesserung ist immer noch genug da.
Sonic
Für mich klingt das in erster Linie fett. Wie viele MB Plattenplatz gehen dafür wieder extra drauf?
feldsee.
ca 319KB (precompiled sqlite 3.3.4 binary - http://www.sqlite.org/download.html)
http://www.sqlite.org/
Beim weiteren Nachdenken ist das natürlich quatsch. Es ist ja vollkommen egal, wie und wo die Bookmarks gespeichert werden, man muss nur einen Standard etablieren, an den sich alle Bookmarks verwendende Applikationen halten. Ich hätte aber eher an LDAP oder ähnliches gedacht. Dort könnte man dann auch zentral alle Adressen und Kalenderdaten speichern.
Bin mal gespannt, ob da irgendwann mal eine Lösung für kommt. Da ich häufig die Browser wechsel, um weder KDE noch Gnome zu vernachlässigen ;), finde ich es sehr wichtig, einen Bookmark-Standard zu haben, der überall benutzt wird. Ggf. könnte man die Datenquelle dann ja auch remote verwenden, ohne seine persönlichen Daten in die Hand eines Bookmark-Verwaltungsservice im Internet anzuvertrauen.
Dafür gibts auch ein Firefox-Plugin: https://addons.mozilla.org/extensions/moreinfo.php?id=1545&application=firefox
Plugins für andere Browser kenne ich jetzt nicht. In den Navigationsbereich des Konqueror lässt es soch noch mittelprächtig integrieren. Allerdings nicht ganz so gut wie in den Firefox. Letzten endes sind die gesammelten Bookmarks aber auch nur über eine Website bereit gestellt, die man mit jedem Browser besuchen kann.
Gruß
Wie ich gerade sehe, ist die grundlegende Installation ja sogar mit "apt-get update sitebar" in debian/sid möglich.
Gruß,
Gert
> was das Pflegen der Bookmarks angeht, deutlich
> unkomfortabler sein, oder?
Nunja.. das Pflegen ohne das Firefox-Plugin ist dann echt nicht sonderlich benutzerfreundlich, was halt an der Natur dieser Browserbezogenen Skripte liegt. Man muss auf eine Einfügenseite der Sitebar gehen, um dann dort die Daten für den neuen Bookmark auszufüllen.
Doch das Plugin für den Firefox macht die Sache dann schon wieder interessanter. Bist Du auf einer Page, die Du bookmarken willst, brauchst du nur die rechte Maustaste drücken und wählst den Eintrag 'Add to SiteBar' aus. Daraufhin öffnet sich ein Fenster, bei dem Du den Ordner angibst, wo der Link gespeichert werden soll. Die url und die Beschreibung der Page ist bereits vorausgefüllt. Das macht die Sache eigentlich genauso einfach wie bei den Broserintegrierten Lesezeichen.
Sitebar ermöglicht obendrein das Importieren und Exportieren von Lesezeichen für die verschiedensten Formate (XBEL, Netscape, Opera, etc).
Gruß,
Martin
Ist ein cgi, das die BM Verwaltung übernimmt, hinzufügen kann man via JS konfortabel aus jedem Browser ohne zusätzliche Plugins. Datenschutz ist mit einem per SSL gesichertem Webserver auch möglich. Lediglich die Verwaltung (verschieben, ordnen) ist etwas rudimentär, aber das Script kann man ja nach Belieben ausbauen.
http://www.linux-magazin.de/Artikel/ausgabe/2004/05/perl/perl.html
lg
Erik
Alles, was dies verunmöglicht, ist unbrauchbar.
Das Strukturieren der Links wird einem dadurch auch nicht abgenommen.
Gruss
August Meier
Das nicht, aber man könnte mehr Möglichkeiten zum Strukturieren bekommen ohne in Wartungsprobleme zu stolpern, also z.B. Lesezeichen zu Artikeln geordnet nach mehreren Kategorien:
ändert sich nun eine URL, so muss man sie nur einmal anpassen und nicht für jede Kategorie einzeln.
> Bookmarks im etablierten HTML-Format?
Steht doch alles da: Performance und Stabilität.
> So können die Bookmarks zumindest mit jedem anderen Browser
> angeschaut oder auch importiert werden und sie sind zur Not
> auch mit einem ASCII-Editor bearbeitbar.
In einem ASCII-Editor brauchen sie nicht bearbeitbar zu sein, weil es sich um Browser-Bookmarks handelt - deswegen bearbeitet man sie im Browser - und zur Benutzung in anderen Browsern gibt es eine Exportfunktionalität.
> Alles, was dies verunmöglicht, ist unbrauchbar.
Nein, natürlich nicht. Man bekommt zwar im Linux-Umfeld immer wieder eingetrichtert, alles, was nicht ASCII ist, sei unbrauchbar, dadurch wird es aber noch lange nicht richtig.
SQLite wird auch in vielen anderen Projekten benutzt und ist dementsprechend getestet und außerdem wird das Places-Feature Dinge miteinander verknüpfen, sie sich gar nicht mehr in standardkonformem HTML abbilden lassen.
>> Bookmarks im etablierten HTML-Format?
>
>Steht doch alles da: Performance und Stabilität.
Schon möglich. Aber seit wann brauchen bookmarks performance?
>> So können die Bookmarks zumindest mit jedem anderen Browser
>> angeschaut oder auch importiert werden und sie sind zur Not
>> auch mit einem ASCII-Editor bearbeitbar.
>
>In einem ASCII-Editor brauchen sie nicht bearbeitbar zu sein, weil es sich um Browser-Bookmarks
>handelt - deswegen bearbeitet man sie im Browser - und zur Benutzung in anderen Browsern gibt es eine
>Exportfunktionalität.
Wie er schon sagte: "... zur Not ...".
Was machst du mit einer Datenbank wenn sie einmal beschädigt ist?
Ich kenne SQLite nicht, aber ein html file kann ich ohne Probleme selbst wieder hinbiegen.
>> Alles, was dies verunmöglicht, ist unbrauchbar.
>
>Nein, natürlich nicht. Man bekommt zwar im Linux-Umfeld immer wieder eingetrichtert, alles, was nicht
>ASCII ist, sei unbrauchbar, dadurch wird es aber noch lange nicht richtig.
ASCII files haben aber eben den grossen Vorteil, das sie von normalen Menschen einfach selbst bearbeitet werden können.
Ich kenne SQLite nicht, aber ein html file kann ich ohne Probleme selbst wieder hinbiegen.
In einer Datenbank kann man Inhalte über die vorgegebene SQL-Schnittstelle viel leichter verwalten als in einer Datei, für die man selber die Zugriffsroutinen schreiben muss. Das, was Du vermutlich mit einer zerschossenen bookmark.html Datei meinst, wird (hoffentlich) mit einer sql-Engine im Hintergrund viel seltener auftreten. Um umfangreich zerstörte Daten dann reparieren zu können braucht man dann eh ein Backup. Da ist es dann egal, ob das eine *.html oder eine *.sqllite Datei ist.
Allerdings kann ich selber auch verstehen, dass man zu einer ASCII-Datei erstmal größeres Vertrauen hat, da man selber einfacher und direkter (per normalem Editor) an die Daten rankommt.
Performance? Bei Bookmarks? lach!
Stabilität? Was genau ist bei HTML unstabil?
Um Daten auch nach Jahren noch bewirtschaften zu können, ist es erforderlich, diese in einem Format abzuspeichern, welches auch dann, wenn dieses Format nicht mehr bewirtschaftet wird, noch gelesen und bearbeitet werden kann.
>>In einem ASCII-Editor brauchen sie nicht bearbeitbar zu sein, weil es sich um Browser-Bookmarks handelt - deswegen bearbeitet man sie im Browser - und zur Benutzung in anderen Browsern gibt es eine Exportfunktionalität.
Das ist Nonsens. Exportfunktionalitäten verlangen definierte Schnittstellen. Wenn diese nicht vorhanden bzw. deren Definitionen nicht offengelegt sind, müssen die Daten bearbeitbar sein und zwar auch ausserhalb der benutzten Applikation, sonst sind sie proprietär formatiert und das wollen wir ja alle nicht, oder?
>>Nein, natürlich nicht. Man bekommt zwar im Linux-Umfeld immer wieder eingetrichtert, alles, was nicht ASCII ist, sei unbrauchbar, dadurch wird es aber noch lange nicht richtig.
Das ist ebensolcher Unsinn. Niemand sagt hier, dass alles, was nicht ASCII sei, unbrauchbar sei. ASCII ist ein für Texte, allenfalls auch Datenbanken geeignetes Format, welches aber auch etwelchen Einschränkungen unterliegt (Diakritische Zeichen, nicht-lateinische Schriften, neue Zeichen wie etc., wo oft auch der erweiterte ASCII-Zeichensatz nicht mehr ausreicht). Für Bookmarks würde er allerdings vollauf genügen. ;-)
Dass SQLite auch in anderen Projekten benutzt wird, macht es nicht schlechter oder besser - es ist für solche Projekte möglicherweise einfach besser geeignet.
Im übrigen wäre zu diskutieren, ob nicht statt eines grundsätzlichen Format-wechsels einfach zu XML gewechselt werden soll, welches weit höheren Anforderungen gerecht wird als selbst HTML 4.
Gruss
August Meier
theile
FF ist ja nicht nur für Linux/Unix Nerds
theile
Andererseits ist es aber doch vollkommen egal. Die Versionsnummer muss eindeutig sein. Ob die 2 oder 3 vor oder hinter dem Komma steht, die Nummer sollte nur streng monoton steigen. Aber es ist schön, dass es uns so gut geht, dass wir uns über so Kleinigkeiten aufregen können.
Die Firefox-Version mit der neuen Rendering-Engine wird dann 3.0 sein.
hoffentlich kommt der wieder mit einem brauchbaren Dateimanager, wie Version vor 1.5 ;-)
Tschau ...
ich-auch
Müsste verboten werden
Zumindest auf meiner 1.5 besteht er ihn immer noch nicht und das ist schon irgendwie... bedenklich.
NikN
du hast Opera vergessen.
Ein echtes Problem ist das sicher nicht - allerhöchstens eine programmiertechnische Herausforderung. 99.9% aller Firefox-Benutzer werden niemals mit solchen Problemen konfrontiert, wie sie beim Smiley-Test auftauchen.
Gruss
August Meier
Das Problem ist, dass das Smiley absolut standardkonform ist und Firefox ihn nicht anzeigen kann. Das bedeutet, dass Firefox nicht standardkonfrom ist.
Ich wollte wissen, ob es überhaupt auf dem Plan von Firefox steht, standardkonform zu werden.
Für mich ist das ein wichtiger Punkt.
Gerade hier hatte ich früher einen wichtigen Vorteil von Mozilla gesehen und jetzt hat sogar Microsoft angekündigt, den Smiley-Test in absehbarer Zeit bestehen zu wollen. Da darf Firefox einfach nicht hinten an stehen.
>Das Problem ist, dass das Smiley absolut standardkonform ist und Firefox ihn nicht anzeigen kann. Das
>bedeutet, dass Firefox nicht standardkonfrom ist.
>Ich wollte wissen, ob es überhaupt auf dem Plan von Firefox steht, standardkonform zu werden.
Im ACID Test befinden sich absichtlich Fehler um zu sehen wie verschiedene Browser darauf reagieren.
>Für mich ist das ein wichtiger Punkt.
>Gerade hier hatte ich früher einen wichtigen Vorteil von Mozilla gesehen und jetzt hat sogar
>Microsoft angekündigt, den Smiley-Test in absehbarer Zeit bestehen zu wollen. Da darf Firefox einfach
>nicht hinten an stehen.
Meine letzte Info sagt was anderes.
MS sagte, das auch die finale Version des IE den ACID Test nicht bestehen wird.
Es ist im Standard genau festgelegt, wie ein Browser auf diese Fehler zu reagieren hat. Ein Browser, der den ACID-Test nicht besteht, ist also zumindest in Bezug auf die Fehlerbehandlung nicht standardkonform.
Am besten finde ich ja da eine Lösung auf Basis von XML. Das lässt sich schön in einen Texteditor lesen/ändern und per XSLT in ein anderes Format konvertieren. Also wenn man der Browser/das OS im Arsch ist, kann ich trotzdem noch meine Bookmarks lesen. Ganz ohne Firefox, einfach mit nen Texteditor. Wird das dann nicht mehr gehn oder verwendet SQLite XML?
Und nein, ich möchte nicht, dass er noch schlanker im Funktionsumfang wird - was ja laut der heutigen offiziellen Wahrheit die Programme leichter benutzbar machen soll, sondern er soll schlanker im Speicherverbrauch werden. Mit der Version 1.5.0.1 hat sich die Situation durch ein paar beseitigte Memory-Leaks zwar leicht gebessert, aber der Effekt, dass der Firefox den Rechner nach ein paar Tagen Laufzeit unbenutzbar macht, weil er sich dann nämlich 70% und mehr des Speichers genehmigt (ca. das dreifache, was Galeon so für sich beansprucht), ist immernoch da.
Auch wäre es toll, wenn es mal wieder eine vernünftige Suchfunktion für die Bookmarks gäbe, eine, die nicht nur Titel-basiert suchen kann (was ja das idiotischste überhaupt ist), und die auch den/die Ordner ausgibt, in denen die Treffer liegen. Das wäre mal eine wirkliche Erleichterung. Und das traurige daran ist, dass das alles schon mal vorhanden war. Stattdessen muss man sich dann mit externen Tools mehr schlecht als recht behelfen.
Naja, nun ändern sie das Backend aufgrund irgendwelcher seltsamer neuer Visionen, zerschlagen damit die Kompatibilität zu dem altgedienten und recht einfach handhabbaren Format, und es sind immernoch nicht die grundlegenden Dinge erledigt.
Könnte es sein, dass du Webbrowser und Webserver verwechselst?
Ich habe zumindest nicht den Anspruch, dass mein Browser mehr als 10 Stunden am Stück laufen muss und dürfte mich damit schon am oberen Ende der Benutzer befinden. Und schneller ist die 1.5 schon deutlich geworden, zumindest unter Linux. Da war die 1.0 bei mir zumindest sau lahm, während der 1.5 praktisch immer flüssig läuft, auch bei vielen komplexen Tabs.
iGEL
Nö.
Um auch mal ne Unterstellungsfrage loszulassen: Kann es sein, dass Du mit Windows vielleicht ganz gut bedient wärst?
Ich habe zumindest nicht den Anspruch, dass mein Browser mehr als 10 Stunden am Stück laufen muss
Ich schon, und warum soll ich mich einschränken müssen, nur damit der Firefox immer der hochgelobte und über jeden Zweifel erhabene Brauser ist, nur weil einige Gelegenheitsnutzer geringere Ansprüche haben? Ich will meinen Brauser intensiv nutzen können, und wenn ichs mal nicht geschafft kriege, alle offenen Tabs abzuarbeiten, dann wird das eben auf die nächsten Tage verschoben. Wieso soll ich den Brauser beenden, wenn es gar nicht nötig ist?
Außerdem klappt das ja mit anderen Brausern wunderbar, also warum sollte man nicht auch an den Firefox diese Ansprüche stellen dürfen?
Und schneller ist die 1.5 schon deutlich geworden, zumindest unter Linux. Da war die 1.0 bei mir zumindest sau lahm, während der 1.5 praktisch immer flüssig läuft, auch bei vielen komplexen Tabs.
Ja, da hat sich schon einiges getan, aber Raum für Verbesserung ist immer noch genug da.
Bei mir läuft manchmal nicht nur der Firefox mehr als 10 Stunden und ich hatte noch nie das Problem das danach mein System nicht mehr geht!