Hallo Besucher, der Thread wurde 106k mal aufgerufen und enthält 727 Antworten

letzter Beitrag von emulaThor am

Webbrowser für 8-Bit-Rechner

  • Man könnte nach Größe und Namen der in den Frames aufgerufenen Seiten gehen.

    Gute Idee, zusätzlich die Größe heranzuziehen, um herauszufinden, welches der Content-Frame ist.


    1. Das Frame mit dem Menu heißt: Menu, das Frame mit dem Hauptinhalt heißt: Content
    2. Die Links in "dem einzigen, großen Bild" sind alle mit ALT-Texten versehen, die zur Erstellung des Hamburger Menüs reichen.

    Die Frame-Namen hatte ich mir schon rausgesucht und die Alt-Texte hatte ich auch gesehen. Ja, damit haben sie natürlich nicht alles MAXIMAL falsch gemacht – aber dennoch ist es ein übles HTML-Gegurke, wie es eigentlich schon zur Jahrtausendwende verschwunden ist. Nichts desto trotz sind wir uns einig, dass man es trotz aller Widrigkeiten doch noch ganz gut parsen kann.


    es wird nicht die einzige Seite sein, die ein BILD oder mehrere Bilder für das Menü benutzt.

    Nicht die Einzige – aber es wird doch selten – und immer seltener – vorkommen.


    area... href... alt könnte man ebenso automatisiert als Linkliste suchen, wie die <li><a href... Geschichten.

    Richtig.


    aber gerade unser Hobby ist weniger "modern" und ich denke, die eine oder andere Seite diesbezüglich arbeitet vermutlich mit sehr "einfachem" HTML bzw. wurden seit Jahren nicht modernisiert.

    Gegen "einfaches" HTML ist nur wenig einzuwenden. Es gibt Webseiten, die ganz simples, Frühzeit-HTML verwenden, um auch den Zugriff mit ganz frühen Browsern, wie Mosaic zu ermöglichen. Üblicherweise verzichten solche Seiten aber auch auf Frames. Aber wir haben ja jetzt gemeinsam eine schöne Lösung erdacht, wie man wahrscheinlich auch über 90% der Frame-Sites "flach-rechnen" könnte.


    Wenn man jedoch eine spezielle "App" schreiben wuerde, um auf dem C64 Software zu finden und herunterzuladen, dann waere diese Software 1:1 drauf zugeschnitten, dass man genau diesen Use Case auf dem C64 durchfuehren kann, und zwar so bequem wie moeglich. Das ist schon ein riesiger Unterschied in meinen Augen.

    Ein riesiger Unterschied. Deswegen bezeichne ich es als Projekt, dass komplett unabhängig vom WWW-Projekt laufen könnte. Ich würde mich freuen, wenn es solche Apps mit Online-Anbindung geben würde (nur eben nicht auf Kosten von einem echten Browser).


    Es schadet ja nicht, verschiedene Konzepte zu erlaeutern bzw. eroertern.

    Auf gar keinen Fall. Einige Sachen haben sich jetzt schon in meinem Kopf deutlich verändert oder auch stärker etabliert.


    Was davon umgesetzt wird, liegt letztendlich an den Programmierern.

    So ist es.


    Es gibt einfach viel zu viele Seiten, die nicht gescheit funktionieren werden. Und genau das waere z.B. fuer mich ein Grund, solch ein Vorhaben gar nicht erst umzusetzen.

    Nein, es sind eine Minderheit an Seiten, die nicht funktionieren würden. Und man kann die Anzahl immer weiter minimieren.


    Für den/die Programmierer dieses Proxy ist es wohl ein wachsendes / endloses Projekt mit wenig Nutzung.

    Jedes Internet-Projekt ist quasi endlos. Das heißt nicht, dass ein Programmiere auf ewig daran gebunden wäre. Ich gehe davon aus, dass so ein Projekt komplett auf OpenSource basieren würde – und so kann jederzeit jemand am Projekt weiter arbeiten, wenn jemand anderes (absichtlich oder unabsichtlich) ausfällt.


    Grundsätzlich ließe sich ja auch die Abfrage einer Seite über diesen Proxy erkennen und dann ggf. eine bereits reduzierte Seite (ähnlich der mobilen Seiten) liefern.

    Das ist natürlich auch eine Idee. Die "C64-Optimierungen", die ZeHa gerne auf der Seite des Servers (C64-Web im Web) oder auf Seite des Clients (spezielle C64-App je Website) hätte, könnte man genauso gut zentral auf dem Proxy erledigen. Bei Zugriff auf sehr spezielle C64-Seiten könnte der Proxy, wenn er dafür vorbereitet ist, auch diese Optimierungen vornehmen und z.B. Download-Listen von der CSDB anbieten. Es gäbe dann eben Ausnahme-Bearbeitungen. Vorteil: Man hätte immer noch das ganze Internet zu Verfügung und trotzdem optimierte Seiten für Spezialwünsche. Und das ganze ohne Sonder-Apps auf dem C64 und alles zentral gepflegt (und nicht im HTML-Code der jeweiligen Ausgangsseite versteckt, wo sich nach 5 Jahren keiner mehr dran erinnert).

  • Und die Technik finde ich eigentlich ganz spannend, vor allem, weil sie sich immer weiter entwickelt und zwar in die richtige Richtung: Weg von proprietärem Mist, wie er jahrelang von Adobe (Flash, Shockwave) und Microsoft (MSN, Direct-X-Controls in IE, IE-Alleingänge, BMP, WMV, WMA ...) propagiert wurde hin zu offenen Standards. Und weg vom Missbrauch von HTML zur Gestaltung von Webseiten hin zu sauberen CSS-Ergänzungen.

    Sehe ich ganz anders. Die Technik entwickelt sich in eine Richtung, in der ein Browser ein aufgedunsenes Etwas mit immer neuen Sicherheitslücken geworden ist, obwohl 95% der User nur Texte mit ein paar Bildchen sehen/lesen wollen. Offene Standards wie CSS, Javascript & Konsorten mögen nett sein, aber wenn sich unter 7,5 Milliarden Menschen niemand findet, der diese Standards ohne eklatante Sicherheitslücken umzusetzen kann, dann sind diese Standards einfach nur eines: ein ganz großer Haufen Mist! Wie viele Jahre hat es gedauert, bis der erste Browser den Acid-3-Test bestanden hat (http://acid3.acidtests.org/)? Allein das zeigt doch, dass die Komplexität dieser sogenannten "Standards" viel zu hoch ist. Ich weiß, dass meine Meinung ziemlich radikal ist. Umso spannender finde ich deshalb einfachere Ansätze wie diesen, die keinen Ghz-Rechner benötigen, um ein paar Texte abzurufen...

  • So, und nun gebe ich auch nochmal meinen Senf zur eigenlichen Sache dazu. :)


    1. Umrechnen einer Seite in Bitmaps halte ich für unpraktikabel. Die Darstellung ist mies und und da die Auflösungen weiter steigen werden, arbeitet die Zeit gegen diesen Ansatz. Generell müssen zu viele Daten übertragen werden.


    2. Umrechnen einer Webseite in Markdown ist eine Sisyphus-Aufgabe, bei der früher oder später jeder Entwickler dem Wahnsinn verfällt. Wirkliche gute Ergebnisse kann man bei 10% der Webseiten erwarten. Und jede Verbesserung, die irgendjemand beiträgt, macht andere Webseiten wieder schlechter lesbar. Dazu kommen ständige nölende User a la "Warum sieht xyz.de so blöd aus?" X(


    Einzig sinnvolle Lösung aus meiner Sicht:
    https://de.wikipedia.org/wiki/Commodore_64?action=raw


    Einfach MediaWiki und DokuWiki unterstützen und schon können sehr viele Seiten angezeigt werden. Es ist relativ einfach selbst eine entsprechende Seite aufzusetzen. Jeder kann also Inhalte zu dieser Art von Web beisteuern. Einen Proxy braucht man nur noch zum Umrechnen von Bildern und vielleicht zur Kompression von Texten. Dazu wäre es toll wenn man sich den ganzen TCP/IP-Overhead spart und einfach eine Art "reliable UDP" verwendet. Wenn sich dann jemand die Mühe machen will und einen Proxy für Nachrichtenseiten und andere Seiten schreiben will, kann er/sie das ja gern tun.


    Seitenbetreiber wie csdb kann man anschreiben. Aus einer bestehenden Datenbank ein passenden MediaWiki/DokuWiki-Quelltext zu erzeugen ist nicht schwer und im Vergleich zum Runterrechnen auf irgendein Markdown eine 100x dankbarere Aufgabe.

  • Ich stimme bei einem Punkt Snear bedenklos zu, das Web zur Zeit ist ein riesiger Clusterfuck. Frames sind da noch ein eher einfacheres Problem. Die funktionieren wenigstens inzwischen auf allen Geräten. Da ist HTML5 noch meilenweit weg von.


    Heute murkst man das ja mit freiflottierenden, sich überlappenden DIVs, da weiß man dann gar nicht mehr, was was ist.


    Ansonsten nur Text rausziehen und empirisch "erkennen", was Menü sein könnte, und was nicht. Selbst der Anordnung von Text/Grafiken würde ich eher ablehnend gegenüberstehen, das wird man einfach nicht hinbekommen (Grafik rechts über dem Text eingeblendet)

  • Sehe ich ganz anders. Die Technik entwickelt sich in eine Richtung, in der ein Browser ein aufgedunsenes Etwas mit immer neuen Sicherheitslücken geworden ist, obwohl 95% der User nur Texte mit ein paar Bildchen sehen/lesen wollen.

    Die Browser werden immer mächtiger und deswegen werden sie natürlich auch immer komplexer und fehleranfälliger. Das liegt aber nicht am Basismodell von HTML, sondern eher daran, dass Firmen, wie Google, aus dem Browser (mittels AJAX ...) ein Betriebssystem machen wollen, auf dem dann Anwendungen, wie Office laufen sollen. Sowas wollen wir hier aber nicht.


    Umso spannender finde ich deshalb einfachere Ansätze wie diesen, die keinen Ghz-Rechner benötigen, um ein paar Texte abzurufen...

    Gerade, weil immer mehr Rechner aus dem Raster fallen und aktuelle Seiten aufgrund von mangelnder Performance und anderem nicht mehr darstellen können, ist unser Ansatz, aus Websieten die reinen Inhalte zu extrahieren ja zukunftsweisend – und nicht nur für ein paar alte C64-Nerds interessant.


    Umrechnen einer Seite in Bitmaps halte ich für unpraktikabel.

    Ich auch. Zumindest so, wie es hier gezeigt wurde. ich hatte den Ansatz selbst schon mal erwähnt aber das ganze wäre, wenn man es wirklich gut machen will, noch viel aufwändiger als die Markdown-Lösung.


    Umrechnen einer Webseite in Markdown ist eine Sisyphus-Aufgabe, bei der früher oder später jeder Entwickler dem Wahnsinn verfällt. Wirkliche gute Ergebnisse kann man bei 10% der Webseiten erwarten.

    Das sehe ich anders. Dafür gibt es schon fertige Tools, an denen man natürlich noch ein wenig herumfrickeln muss. Und fast alles, was ich bisher durch Lynx geschickt habe, ließ vermuten, dass man das noch ein wenig aufbereiten und am Schluss sehr gut zu MD konvertieren könnte. Und wie schon mehrfach gesagt: Markdown MUSS NICHT. Es ist nur ein zusätzlicher Optimierungsschritt. Auch simplifiziertes HTML (per Proxy) ist vollkommen OK und wäre schon 3 x so schnell, wie das, was Contiki so treibt.


    Einfach MediaWiki und DokuWiki unterstützen und schon können sehr viele Seiten angezeigt werden.

    Das halte ich für utopisch, kann aber gerne gemacht werden. Ich habe nichts gegen Wikis, die kann man toll im Browser darstellen.


    Seitenbetreiber wie csdb kann man anschreiben. Aus einer bestehenden Datenbank ein passenden MediaWiki/DokuWiki-Quelltext zu erzeugen ist nicht schwer und im Vergleich zum Runterrechnen auf irgendein Markdown eine 100x dankbarere Aufgabe.

    Nur ist man eben auf Gedeih und Verderb auf Dutzende, einem gewogene, Seitenbetreiber angewiesen. Man kann es gerne ausprobieren und nachfragen, ob die dazu Lust haben. Vielleicht klappt es ja. Das kann man sogar neben diesem Projekt machen – wie auch das Programmieren von C64-Apps für die CSDB und Co.


    [Frames] funktionieren wenigstens inzwischen auf allen Geräten. Da ist HTML5 noch meilenweit weg von.

    Frames funktionieren, weil sie uralt sind. Hoffentlich wirft Google die Unterstützung bald mal aus Chrome raus – dann müssen sich die Ewiggestrigen mal wieder im Sarg bewegen. ;)


    HTML 5 funktioniert meines Erachtens in den aktuellen Browsern (IE zählt nicht dazu) sehr gut aber das ist gar nicht der Punkt. Wir wollen ja bis auf ein paar semantische Basis-Tags alles (vor allem HTML5-spezifischen Code) herauswerfen – nicht interpretieren. Und wo heutige Seiten eben viel viel besser sind als die von vor 15 Jahren, ist, dass man DAS zu 99,9% kann – ohne dass einem alles um die Ohren fliegt.


    Wenn du heute alle DIV-Strukturen ignorierst, sind die Inhalte zu nahezu 100% immer noch in einer sinnvollen Reihenfolge. Das wäre bei alten Tabellenstrukturen, denen du die TDs und TRs entreißt, nicht so.


    Heute murkst man das ja mit freiflottierenden, sich überlappenden DIVs, da weiß man dann gar nicht mehr, was was ist.

    Diese ganzen Sachen mit überlappenden DIVs, Canvas, Video usw. sind vor allem ersonnen worden, um die Leute zufrieden zu stellen, die zuvor mit Flash herumgespielt haben. Jetzt können sie den ganzen Unsinn (vor allem Werbung) auch mit HTML (5) machen. Nur tauchen diese Konstrukte eben so gut wie nie auf Informationsorientierten Seiten, wie Foren, Wikis, Tech-Nachrichten, allgemeinen News-Seiten, Blogs, CMS-basierten Seiten etc. auf. Daher muss uns das nicht so sehr interessieren. Für die C64-User ist es wichtiger, wenn Forum64 und heise.de funktionieren, als wenn die Seiten von Porsche und Milka funktionieren würden.

  • Grade der letzte Absatz wirft ein interessantes Problem auf: Kaum jemand der versierteren Benutzer ist ohne Adblocker unterwegs. Sowas müsste man ja eigentlich auch eingebaut haben, die Werbung gehört ja klar aussortiert.


    Ach herrje, man müsste einfach mal anfangen, ein paar Varianten ausprobieren und sich dann für eine entscheiden. Das Runterrechnen stelle ich mir fast einfach vor, wogegen das sinnvolle Anordnen (falls überhaupt) am C64 deutlich kniffliger wird. Eine schöne Hires-Text-Schrift und dann Bilder dazu. Allein das ganze Layout-Geraffel muss man ja fast durchgehend vergessen (DTP willst du am C64 nicht mehr machen, nicht mal ich bin so abgedreht :) )


    Ich denke mal, UTF8 fällt auch flach, viel weiter als ASCII wird es nicht reichen.

  • Einzig sinnvolle Lösung aus meiner Sicht:
    de.wikipedia.org/wiki/Commodore_64?action=raw

    DAS gefällt mir! Damit kann man doch arbeiten.


    Der Proxy würde liefern, was immer der Browser haben möchte

    Was ich mir ich mir dann vom Proxy hauptsächlich wünschen würde, wäre eine Umwandlung der TAGs etc. in ein besser C64-verdauliches Format (z. B. "@@" oder ähnliches als Ankündigung eines Steuerzeichens, wie ich es jetzt auch in meinem Programm verwende).


    Bei dieser Speicheraufteilung würde ein Sprung auf die nächste vertikale Bildschirmseite (man könnte aber auch beispielsweise nur halbseitenweise hüpfen, um den Lese-Anschluss nicht zu verlieren) diese dann aus dem RAM gerendert werden. Das wäre schon mal deutlich schneller als bei Contiki, der anscheinend beim Umschalten schon aus dem Netz nachladen muss. Alles, was noch nicht ins C64-RAM passt, würde vom Proxy vorgehalten und bei Bedarf nachgeladen werden.

    Absolut denk- und machbar (also C64-seits meinerseits).


    Man könnte aber auch schon etwas mehr Screen "vorrendern", damit man ein Bitmap-Scrolling realisieren kann. Bitmap-Scrolling ist nicht utopisch

    Ja.


    Einfach MediaWiki und DokuWiki unterstützen und schon können sehr viele Seiten angezeigt werden. Es ist relativ einfach selbst eine entsprechende Seite aufzusetzen. Jeder kann also Inhalte zu dieser Art von Web beisteuern. Einen Proxy braucht man nur noch zum Umrechnen von Bildern und vielleicht zur Kompression von Texten. Dazu wäre es toll wenn man sich den ganzen TCP/IP-Overhead spart und einfach eine Art "reliable UDP" verwendet. Wenn sich dann jemand die Mühe machen will und einen Proxy für Nachrichtenseiten und andere Seiten schreiben will, kann er/sie das ja gern tun.

    :thumbup:


    Gerade, weil immer mehr Rechner aus dem Raster fallen und aktuelle Seiten aufgrund von mangelnder Performance und anderem nicht mehr darstellen können, ist unser Ansatz, aus Webseiten die reinen Inhalte zu extrahieren ja zukunftsweisend – und nicht nur für ein paar alte C64-Nerds interessant.

    Da geht mir jetzt aber grad mal durch den Kopf, wie das ganze eigentlich rechtlich zu bewerten wäre :roll: . Man bedienst sich fremder Seiten (Urheberrecht o. ä.), bricht diese auf ein Minimum herunter (Ade Impressum & Co.) und verbreitet diese (unauthorisiert) über einen Proxy weiter? Hmm... :gruebel

  • Wie von mir erwartet: Unlesbar – und die sind sogar noch kantengeglättet, was der C64 in Hires nicht tun könnte. Das ist halt kein zielführender Ansatz – außer es kommt noch das Kaninchen aus dem Hut gesprungen.

    Pardon, man muss sich schon für 5 Pfennig Mühe geben. Soll heissen: Man darf natürlich nicht einfach Screenshots von seinem Firefox zum c64 übertragen sondern muss die hinter dem Browser (FF, Chrome, whatever) stehende Engine dergestalt modifizieren das sie eine c64-gerechte Grafik rendert. Bei Links hatte ich das ja schon mal versucht indem ich einen Zeichensatz von GEOS da hereingefrickelt habe. Und an den Stellen, an denen er diesen Zeichensatz auch unskaliert verwendet hat, ist das Ergebnis für meine Begriffe durchaus brauchbar.
    Immerhin könnte man auf diese Weise (also indem man eine leistungstarke Engine auf dem Proxy die Bitmaps rendern lässt) auch leicht mit Frames, Tables, Imagemaps, UTF8 und all dem anderen Mist fertig werden. Adblocker lassen sich ebenfalls einbinden. Und das Resultat ließe sich spielend leicht in C64-gerechte Portionen segmentieren (der c64 könnte z.B. jeweils nur einen bestimmten Ausschnitt der Bitmap vom Proxy anfordern, je nachdem wieviel Speicher der jeweilige Browser zur Verfügung hat)*.


    Manchen gehen meine Vorstellungen ja noch nicht weit genug – sie wollen komplette Desktop-Webseiten auf 320 Pixeln Breite darstellen, mehrspaltige Original-Layouts erhalten und noch mehr. Ich sage dazu nur: Wenn die jemanden damit überzeugen können, die Sache anzugehen und zu programmieren, soll es mir recht sein. Ich denke, dass meine eigenen Wunschvorstellungen sehr realistisch und gut umsetzbar sind. Aber auch für diesen Ansatz habe ich leider (noch) keinen Entwickler zur Hand. Es bleibt das Prinzip Hoffnung.

    Wenn ich mich mal vorrübergehend als potentiellen Entwickler bezeichnen darf: Deine Vorstellung des ASCII-Browsens ist mir schlicht und einfach zu uninteressant um mich noch großartig damit auseinanderzusetzen. Wenn ich für das Projekt schon nicht bezahlt werde dann muss es doch zumindest für mich selber irgendwie interessant sein, denn ansonsten verbringe ich meine Freizeit anderweitig. Eine grafische Darstellung von Webseiten auf dem c64 (und ähnlichen Devices) finde ich hingegen (im Augenblick noch) interessant, da es eine neue Herausforderung darstellt. Irgendwelche ASCII-Texte auf dem c64 anzuzeigen finde ich dagegen ausgesprochen öde. Bei dieser Zielsetzung wäre ich 'raus.


    Nochmal zum Thema Markdown:
    Diese kann beliebige Seiten in Markdown umrechnen. Von den 6-7 Seiten, die ich spontan mal probiert habe, war etwas die Haelfte unbrauchbar.

    Ja, zu dem gleichen Schluß kam ich ebenfalls. Aber umgekehrt bedeutet das ja auch das ein c64 das halbe WWW handhaben könnte! 8o


    Ich sehe das durchaus anders. Man darf nicht den Fehler machen, das Ergebnis eines einzelnen Konvertierungstools für die eigenen Entscheidungen zugrunde zu legen.

    Auf der anderen Seite möchte ich aber auch nicht den Fehler machen und die Ausgabe zu stark einzuschränken. Die Möglichkeiten des Proxies und die Möglichkeiten eines Browsers sind ja durchaus zwei Paar Schuhe.


    Die Technik entwickelt sich in eine Richtung, in der ein Browser ein aufgedunsenes Etwas mit immer neuen Sicherheitslücken geworden ist, obwohl 95% der User nur Texte mit ein paar Bildchen sehen/lesen wollen.

    Was womöglich dazu führt das auch nicht-c64-user den Dienst nutzen wollen würden. :)



    Irgendjemand schrieb weiter oben das es ja schon einen massiven Usecase abbildet wenn man Forum64, CSDB, Gamebase etc. handhaben könnte. Ich weiss gerade leider nicht mehr wer das war, aber ich möchte ihm zustimmen. Wenn man mit einem c64 nicht bei Amazon einkaufen oder sich mit google maps die Landschaft angucken kann, dann wäre das für mich völlig Latte. Das würde ich ohnehin nicht am c64 machen wollen.



    Neues Thema: Ich habe das oben verlinkte Paper mal weiterverfolgt und musste dabei feststellen, daß genau das hier angesprochene Problem (WWW auf Devices mit low resources) schon um die Jahrtausendwende ein Thema der Forschung war. Damals ging es um PDAs wie den Palmpilot, welche ja bisweilen noch viel dürftigere grafische Möglichkeiten boten als der c64. Na jedenfalls scheint es damals eine ganze Menge Aufsätze gegeben zu haben die sich mit allen Facetten der Problematik auseinandersetzen (u.a. auch mit der Reduktion/reshaping/reflowing des Contents einer Webseite). Keine Ahnung inwieweit die damaligen Erkenntnisse heute noch praxistauglich sind, doch diese Aufsätze stellen für uns nun freilich eine Fundgrube des Wissens dar. Da müssten wir uns einfach mal hinsetzen und uns durchwühlen. "Vereinfachende Proxies" waren seinerzeit offenbar auch Gang und Gäbe, und wenn Archive.org gerade nicht im maintenance-modus wäre würde ich auch sofort mal nachschauen was es damals so gab. :)
    Möglicherweise kann man ja Überreste des alten Zeugs heute noch auf Sourceforge/Github/etc. finden?



    Wo ich evtl. noch einen Lichtblick drin sehe: Viele Seiten heutzutage basieren ja auf den gleichen Frameworks wie WordPress usw, vielleicht kann man zumindest hier einen Ansatz finden, um diese Seiten vernuenftig darstellen zu koennen.

    Hmm, ich möchte hier mal anmerken das sich der gesamte Thread im Kreis zu drehen scheint. Er zieht sich schon seit Monaten wie Kaugummi, und kaum wer scheint sich noch daran erinnern zu können was bereits geschrieben wurde (falls derjenige es überhaupt jemals gelesen hat). Vielleicht wäre es nun an der Zeit das sich eine Gruppe von versierten Interessenten zusammensetzt um nicht mehr darüber zu grübeln "ob irgendetwas möglich ist" sondern "was möglich ist" und vor allem "wie es möglich ist".
    By the way, es ist heute auf den Tag genau drei Wochen her, da habe ich noch in einem ganz anderen Forum geschrieben: "PS: Wir sind hier in einem deutschen Forum, hier wird man sowieso nur mit "gibt's schon", "geht nicht" oder "braucht man nicht" reagieren. ;-)"
    Wie wahr, wie wahr... ;)


    Ja nun, also ich zähle jetzt mal Retrofan und mich selbst in die Gruppe derjenigen, die sich auf den Weg machen wollen um dem C64 das WWW beizubringen. Wo auch immer wir am Ende landen.
    Gibt's noch mehr unerschrockener Freiwillige, die ins Unerforschte aufbrechen möchten? :)



    * Als (klitzekleines) Bonbon habe ich die Überreste eines Writers ausgegraben den ich vor ca. 20 Jahren geschrieben hatte. Die Texte mussten dabei in einer selbstgebastelten Beschreibungssprache verfasst werden, was zwar etwas umständlich war aber den Vorteil hatte das man auch leicht Grafiken einbinden oder den Zeichensatz ändern konnte (es wurden u.a. auch Fonts von GEOS, Pagefox und TTF unterstützt). Der Writer war ein ewiges W.i.P.-Projekt (tatsächlich bekomme ich ihn heute nicht mal mehr kompiliert - mann, was habe ich damals für eine Sch... programmiert), aber ich habe noch eine lauffähige Testnote von damals gefunden.
    Na jedenfalls: Der Writer interpretierte eine Beschreibungssprache und renderte daraus eine große Bitmap in einem c64-tauglichen Format. Die Bitmap wurde anschließend in jeweils 8 Pixel hohe Stripes unterteilt, welche jeweils unabhängig voneinander ge(char)packt wurden. Der Reader auf dem c64 konnte die Bitmap nun bei Bedarf Stripe für Stripe entpacken und darstellen. Soweit ich mich erinnere ging dies ziemlich problemlos.
    Worauf ich hinaus möchte ist: Das angedachte Konzept, nähhmlich das ein PC eine Beschreibungssprache rendert und daraus eine Grafik für den c64 rendert, ist durchaus tragfähig. Da ein Browser die Daten ja nicht each-Frame entpacken können müsste (wie es der Reader hier macht) wären hier noch ganz andere Kompressionsverfahren denkbar. In diesem Beispiel wird nur (allereinfachstes) Charpacking genutzt, und schon allein dadurch kann man mehrere Seiten Bitmaps im Speicher des c64 unterbringen. Bei ausgefuchsteren Kompressionsverfahren ist sicherlich noch einiges mehr drin. Auch mit Meta-Informationen.


    Naja, also hier jedenfalls die allererste veröffentliche Note des Writers. Seid stolz, das ihr diesem Augenblick - als erste Menschen überhaupt - beiwohnen dürft! ^^
    robby.prg

  • Naja, also hier jedenfalls die allererste veröffentliche Note des Writers. Seid stolz, das ihr diesem Augenblick - als erste Menschen überhaupt - beiwohnen dürft!
    robby.prg

    Wirklich echt nett anzuschauen! Aber das sind wohl vier(?) vorgefertigte Bitmaps, so wie ich das verstanden habe (EDIT: Ja, das "Stripe-weise" quasi). Ist nicht so ganz zielführend für diese Sache, denke ich. Aber trotzdem natürlich schick (vom fiesen Flackerrand und den fehlenden Umlauten mal abgesehen). Und: Ja, ich weiß, wie viel Arbeit allein so ein Proportional-Kram macht. Respekt für die Arbeit (und das für die damalige Zeit).


    Aber auf jeden Fall interessant zu sehen, wie schnell Bitmap-Scrolling doch sein kann, wenn die Daten (davor/dahinter) schon fertig rumliegen.

  • Da geht mir jetzt aber grad mal durch den Kopf, wie das ganze eigentlich rechtlich zu bewerten wäre . Man bedienst sich fremder Seiten (Urheberrecht o. ä.), bricht diese auf ein Minimum herunter (Ade Impressum & Co.) und verbreitet diese (unauthorisiert) über einen Proxy weiter? Hmm...

    Ging mir auch so beim lesen durch den Kopf, habe es dann verworfen und... Du schreibst es.
    Wenn die Quellenangabe dabei ist, könnte man auch "aufgearbeitetes Material" als Zitat bezeichnen?!


    Was ich mir ich mir dann vom Proxy hauptsächlich wünschen würde, wäre eine Umwandlung der TAGs etc. in ein besser C64-verdauliches Format (z. B. "@@" oder ähnliches als Ankündigung eines Steuerzeichens, wie ich es jetzt auch in meinem Programm verwende).

    Vielleicht wäre es ja mal hilfreich dieses verdauliche Format "fest"-zulegen.


    Immerhin könnte man auf diese Weise (also indem man eine leistungstarke Engine auf dem Proxy die Bitmaps rendern lässt) auch leicht mit Frames, Tables, Imagemaps, UTF8 und all dem anderen Mist fertig werden. Adblocker lassen sich ebenfalls einbinden. Und das Resultat ließe sich spielend leicht in C64-gerechte Portionen segmentieren (der c64 könnte z.B. jeweils nur einen bestimmten Ausschnitt der Bitmap vom Proxy anfordern, je nachdem wieviel Speicher der jeweilige Browser zur Verfügung hat)*.

    Würde sich ggf. als "zweiter Modus" anbieten. Wenn die Runterrechnung des Quelltextes tatsächlich nur Müll bringt (z.B. aufgrund chaotisch angeordneter DIVs oder aufgrund von Tabellen), dann kann man den Modus wechseln.


    Wenn ich mich mal vorrübergehend als potentiellen Entwickler bezeichnen darf: Deine Vorstellung des ASCII-Browsens ist mir schlicht und einfach zu uninteressant um mich noch großartig damit auseinanderzusetzen. Wenn ich für das Projekt schon nicht bezahlt werde dann muss es doch zumindest für mich selber irgendwie interessant sein, denn ansonsten verbringe ich meine Freizeit anderweitig. Eine grafische Darstellung von Webseiten auf dem c64 (und ähnlichen Devices) finde ich hingegen (im Augenblick noch) interessant, da es eine neue Herausforderung darstellt. Irgendwelche ASCII-Texte auf dem c64 anzuzeigen finde ich dagegen ausgesprochen öde. Bei dieser Zielsetzung wäre ich 'raus.


    Eigene Begeisterung für so ein Projekt ist wohl unverzichtbar. Und wenn Retrofan das nicht als sein Projekt sieht, bei dem er peitsche schwingend diktiert was zu machen ist, dann liegt es wohl an Dir, als (vorrübergehend) potentiellen Entwickler, das ganze nach Deinem Geschmack zu formen.


    Er zieht sich schon seit Monaten wie Kaugummi, und kaum wer scheint sich noch daran erinnern zu können was bereits geschrieben wurde (falls derjenige es überhaupt jemals gelesen hat). Vielleicht wäre es nun an der Zeit das sich eine Gruppe von versierten Interessenten zusammensetzt um nicht mehr darüber zu grübeln "ob irgendetwas möglich ist" sondern "was möglich ist" und vor allem "wie es möglich ist".


    ... die Schwachstellen eines Forums... selbst wenn man was gelesen hat, ist die Erinnerung oft schwach. Wir brauchen ein Whiteboard: Vorgeschlagen - Diskutiert - Pro - Contra (o.ä.)


    Keine Ahnung inwieweit die damaligen Erkenntnisse heute noch praxistauglich sind, doch diese Aufsätze stellen für uns nun freilich eine Fundgrube des Wissens dar. Da müssten wir uns einfach mal hinsetzen und uns durchwühlen. "Vereinfachende Proxies" waren seinerzeit offenbar auch Gang und Gäbe, und wenn Archive.org gerade nicht im maintenance-modus wäre würde ich auch sofort mal nachschauen was es damals so gab.

    Die gestellten Fragen dürften sich damals geähnelt haben. Die Ergebnisse sollten heute ja doch etwas anders ausfallen.


    Naja, also hier jedenfalls die allererste veröffentliche Note des Writers. Seid stolz, das ihr diesem Augenblick - als erste Menschen überhaupt - beiwohnen dürft!
    robby.prg

    Ich verkünde mit Stolz: Ich habe beigewohnt.
    Das sieht doch echt brauchbar aus. Wenn das dann im "verdaulichen Format" gelieferten Input ausgibt, wäre das mal 'ne Grundlage auf c64 Seite.



    Gegen "einfaches" HTML ist nur wenig einzuwenden. Es gibt Webseiten, die ganz simples, Frühzeit-HTML verwenden, um auch den Zugriff mit ganz frühen Browsern, wie Mosaic zu ermöglichen. Üblicherweise verzichten solche Seiten aber auch auf Frames. Aber wir haben ja jetzt gemeinsam eine schöne Lösung erdacht, wie man wahrscheinlich auch über 90% der Frame-Sites "flach-rechnen" könnte.

    Als einfaches HTML meinte ich eben eben auch gerade die Frames, Bildmenüs und Tabellen. Und ich vermute, dass wir bei Tabellen das eine oder andere mal nur Schrott bekommen.
    Aber das gilt vermutlich generell für Tabellen, vielleicht noch mehr für richtige Tabellen.



    Jedes Internet-Projekt ist quasi endlos. Das heißt nicht, dass ein Programmiere auf ewig daran gebunden wäre. Ich gehe davon aus, dass so ein Projekt komplett auf OpenSource basieren würde – und so kann jederzeit jemand am Projekt weiter arbeiten, wenn jemand anderes (absichtlich oder unabsichtlich) ausfällt.

    Auch wieder wahr.


    Das ist natürlich auch eine Idee. Die "C64-Optimierungen", die ZeHa gerne auf der Seite des Servers (C64-Web im Web) oder auf Seite des Clients (spezielle C64-App je Website) hätte, könnte man genauso gut zentral auf dem Proxy erledigen. Bei Zugriff auf sehr spezielle C64-Seiten könnte der Proxy, wenn er dafür vorbereitet ist, auch diese Optimierungen vornehmen und z.B. Download-Listen von der CSDB anbieten. Es gäbe dann eben Ausnahme-Bearbeitungen. Vorteil: Man hätte immer noch das ganze Internet zu Verfügung und trotzdem optimierte Seiten für Spezialwünsche. Und das ganze ohne Sonder-Apps auf dem C64 und alles zentral gepflegt (und nicht im HTML-Code der jeweiligen Ausgangsseite versteckt, wo sich nach 5 Jahren keiner mehr dran erinnert).

    Das hatte ich her mit....

    Wenn der Betreiber einer Seite allerdings die Mögichkeit hat die "Datenbank" zur Optimierung der Anzeige seiner Seite auf <32 Bit Hardware etwas zu füttern, ist das vielleicht noch ein Überschaubarer aufwand für diesen...

    gemeint. In dem von Dir zitierten Teil meinte ich eigentlich tatsächlich einen alternativen Quelltext, den der Seitenbetreiber liefern kann.
    Die aufgerufene Seite erkennt eine Anfrage vom Proxy und liefert die extra dafür im "verdaulichen Format" erstellte Seite, die der Proxy dann 1:1 weiterreicht. Für den, der am c64 sitzt kein erkennbarer Unterschied, aber erhält die Seite exakt so, wie der Seitenbetreiber es wünscht. So kann jeder, der es wünscht, Internet für den c64... oder Atari 800xl oder Amiga (...) machen. Der Browser kann aber immer direkt über den Proxy gehen.

  • Super, da scheint ja ein Entwickler interessiert zu sein. Hätte ich fast nicht mehr daran geglaubt. Vielen Dank Rapid Eraser! (Da ich ein Fan von Austria Wien bin, finde ich diesen Nicknamen besonders gut ;-)

    Der Writer interpretierte eine Beschreibungssprache und renderte daraus eine große Bitmap in einem c64-tauglichen Format. Die Bitmap wurde anschließend in jeweils 8 Pixel hohe Stripes unterteilt, welche jeweils unabhängig voneinander ge(char)packt wurden. Der Reader auf dem c64 konnte die Bitmap nun bei Bedarf Stripe für Stripe entpacken und darstellen.

    Verstehe ich das richtig:
    Der Proxy soll eine Seite aufrufen
    daraus eine Bitmap, also eine Grafik erstellen,
    diese in kleine Häppchen zerlegen und
    scheibchenweise an den C64 senden,
    der die Teile wieder zusammensetzt?


    Wenn das so ist, handelt es sich dann um einen reinen Reader oder werden Eingabezeilen, Links usw. trotzdem möglich sein?

  • Schön, dass sich ein Entwickler gefunden hat der sich dieser Aufgabe annimmt. Ich bin sehr auf die ersten Ergebnisse gespannt.

    Da stehen dir einige spannende Jahre bevor! ^^
    Mein Enthusiasmus reicht gerade nur soweit das ich mich näher in das Thema einlesen mag. Ein produktives Release strebe ich derzeit nicht an, sorry. Und da Retrofan und ich zwar am gleichen Strick ziehen, aber in unterschiedliche Richtungen, wäre es sicher sehr sachdienlich wenn sich weitere Entwickler fänden.



    [...]
    Würde sich ggf. als "zweiter Modus" anbieten. Wenn die Runterrechnung des Quelltextes tatsächlich nur Müll bringt (z.B. aufgrund chaotisch angeordneter DIVs oder aufgrund von Tabellen), dann kann man den Modus wechseln.

    Denkbar ist das sicherlich, macht aber wahrscheinlich auch gleich wieder mehr Arbeit. Unterschiedliche Modi wollen womöglich alle einzeln gepflegt/getestet/debugt/weiterentwickelt/angepasst werden.
    Das läuft halt wieder auf die Frage hinaus: Geht es einem bei der ganzen Sache um Emotionen oder um Funktionalität/Entwicklungsaufwand? Ich selber habe eher letzteres im Auge. Und da selbst im Forum64 die Begeisterung für einen Webbrowser auf dem c64 bislang.. naja, eher verhalten war spielt der Aufwand (für mich) eine umso größere Rolle.
    In einem anderen Thread hier im Forum geht es gerade um ein Wifi-Modem für $50. Ist ja auch fein. Aber für das gleiche - oder weniger - Geld kann man auch einen Raspi (0W) o.Ä. an den c64 anflanschen, der dann die gesamt Kommunikation mit dem Internet übernimmt, die Webseiten rendert und anschließend als Bitmap mitsamt Metainformationen in den c64 pumpt. Dabei bleibt vielleicht das Gefühl das ein c64 alles kann auf der Strecke, aber zweckmäßig wäre es allemal:
    - man braucht keinen (öffentlichen?) Proxy zu betreiben
    - rechtliche Fragen erübrigen sich
    - wenn man dem RasPi mitteilt was der User getippt hat/wohin er geklickt hat wären auch popup-menus mit JS oder Vervollständigungsvorschläge in Eingabefeldern denkbar
    - https wäre ebenfalls kein Problem
    - downloads von d64s o.ä. gingen fix, und die unterschiedlichen Formate könnten auch gleich entpackt werden
    - auch der Anschluß des Raspis wäre einfach (WLAN)
    - Himmel, je nach Datendurchsatz könnte man sogar versuchen Youtube-Videos auf dem c64 abzuspielen (der Raspi könnte sie ja ersteinmal komplett herunterladen, dann konvertieren, und dann mit - k.A. - 5 Frames pro Sekunde + miesem Digisound an den c64 schicken?)
    - zusätzlich könnte man ein solches Modul auch noch für andere Zwecke als Webbrowsen verwenden
    Kurzum: Von der Funktionalität und vom Arbeitsaufwand her fänd ich diese Option durchaus interessant. Aber ich fürchte das dann selbst Retrofan abspringt und somit am Ende gar kein User mehr übrigbleibt... ;(


    ... die Schwachstellen eines Forums... selbst wenn man was gelesen hat, ist die Erinnerung oft schwach. Wir brauchen ein Whiteboard: Vorgeschlagen - Diskutiert - Pro - Contra (o.ä.)

    Sehe ich auch so. Subjektive Spekulationen über alle Facetten eines solchen Projekts wurden mittlerweile glaube ich hinreichend geäußert. Nun wäre es angebracht das sich ein optimistisches Team bildet welches tatsächlich mal versucht auf dem Gebiet vorran zu kommen.


    Ich verkünde mit Stolz: Ich habe beigewohnt.

    Das ist die richtige Antwort! Genau so geht das! :thumbsup:


    Danke! Aber ich musste ehrlich gesagt ersteinmal googeln um das mit Austria Wien zu verstehen. :D Hatte den Nick damals von einem herumliegen Radiergummi abgeschrieben...
    Und ja, die Scheibchenweise Übertragung einer Bitmap (+Metainformationen) halte ich durchaus für eine praktikable Option.

  • Kaum jemand der versierteren Benutzer ist ohne Adblocker unterwegs. Sowas müsste man ja eigentlich auch eingebaut haben, die Werbung gehört ja klar aussortiert.

    Bei meinem Ansatz würde Werbung automatisch wegfallen, weil die ja meistens nicht klartextlich im HTML steht, sondern in verschiedenen Formaten eingebunden wird (Bilder, Flash, JavaScript, iFrames ...). Wenn ich z.B. die (mit Werbung vollgestopfte) Heise-Seite durch Lynx jage, ist da kein bisschen Werbung mehr.


    Ach herrje, man müsste einfach mal anfangen, ein paar Varianten ausprobieren und sich dann für eine entscheiden.

    Falls du mit Varianten unterschiedliche Lösungsansätze meinst, wäre das natürlich optimal. Jeder hier hat natürlich andere Favoriten, was die möglichen Web-Darstellung für C64 und Co. angeht. Die einen wollen komplexe Seitenstrukturen inkl. Layout, Bildern und allem anderen darstellen, anderen reicht etwas besseres ASCII (Contiki mit Umlaute und Formulare) oder Bildschirmtext, die einen wollen von den Seitenbetreibern, dass die ihre Seiten C64-freundlich patchen, andere wollen Apps für bestimmte Seiten haben. Noch andere wollen das ganze Internet dazu bringen, andere Techniken als "komplexes" HTML5 zu verwenden oder einfach ein paar C64-spezifische Infos irgendwo hinlegen, wo man sie lesen kann. Und ich sortiere mich da eher in der Mitte ein: Deutlich schicker, lesbarer und benutzerfreundlicher als Contiki aber dennoch ohne Erhaltung des Original-Layouts – nur eine App für den C64 (Browser) und ohne die Seitenbetreiber ansprechen zu müssen, ob die ihre Seiten umbauen wollen. Dafür aber das "ganze" Internet und nicht nur ein paar Seiten.


    Aber welcher Ansatz wirklich zielführend wäre, wissen wir natürlich nicht. "Meiner" (der nicht neu ist) kann genauso scheitern, wie andere Erfolg haben könnten. Die Chance auf etwas funktionierendes steigt natürlich mit der Anzahl der ausprobierten Ansätze. Nur gibt es Leute, die Alternativen testen wollen?


    Eine schöne Hires-Text-Schrift und dann Bilder dazu. Allein das ganze Layout-Geraffel muss man ja fast durchgehend vergessen

    Das wäre ja tendenziell auch mein Favorit.


    Ich denke mal, UTF8 fällt auch flach, viel weiter als ASCII wird es nicht reichen.

    Warum? Ich propagiere von Anfang an UTF-8-Ntzung, schon alleine, weil ASCII keine Umlaute kennt. Ein üblicher C64-Font enhält 256 Chars – und ich würde die untersten 256 Zeichen von UTF-8 verwenden wollen. Warum soll der C64 das nicht können? In einen 2 KB Zeichensatz könnte man ASCII und alle westeuropäischen Sonderzeiten reinpacken.


    Was ich mir ich mir dann vom Proxy hauptsächlich wünschen würde, wäre eine Umwandlung der TAGs etc. in ein besser C64-verdauliches Format (z. B. "@@" oder ähnliches als Ankündigung eines Steuerzeichens, wie ich es jetzt auch in meinem Programm verwende)

    Was ist daran jetzt so anders als das von mir ins Spiel gebrachte Markdown?


    Da geht mir jetzt aber grad mal durch den Kopf, wie das ganze eigentlich rechtlich zu bewerten wäre . Man bedienst sich fremder Seiten (Urheberrecht o. ä.), bricht diese auf ein Minimum herunter (Ade Impressum & Co.) und verbreitet diese (unauthorisiert) über einen Proxy weiter? Hmm...

    Zum einen: Das tun der Google-Proxy und Opera genauso und ich habe noch nie gehört, dass es damit rechtliche Probleme gegeben hätte. Das Impressum bleibt natürlich erhalten – wie alle Inhalte auch, was sonst? Und es wird nichts "verbreitet", sondern auf Anfrage eines Browsers optimiert, also quasi nur Browser-Intelligenz ausgelagert. Die Seitenbetreiber haben ja nie Einfluss darauf, wie der Betrachter sich die Seiten anguckt.


    Zum anderen: Das Projekt wäre so klein und begrenzt, dass es sicherlich kein (klagendes) Schwein kümmern würde. Und das Internet würde dadurch ja mehr Geräten erschlossen werden, nicht weniger.

  • Also insbesondere https wäre wohl ein Topargument für den lokalen RasPi-Proxy.
    Aber auch im Falle eines lokalen Proxy entsteht ähnlich erheblicher Programmieraufwand. Ich hab' mich allerdings auch noch nicht ehrlich damit beschäftigt RasPi und Cevi zusammen zu bringen.
    Würde ich aber wohl, wenn es eine solche Lösung gäbe bzw. wenn ich irgendwie an der Entwicklung helfen könnte.
    Würde sich denn aber insgesamt die Kommunikation mit dem Raspi so sehr von der Kommunikation z.B. über das WLAN Modem an einen öffentlichen Server unterscheiden (programmiertechnisch)?


    Wäre der RasPi in Deiner Vorstellung einzig und allein zu diesem Zweck in Betrieb oder würde dort im Prinzip alles im Hintergrund abgewickelt?



    Also diskutieren wir jetzt weiter oder macht der Chef jetzt mal 'n Tafelbild? :D

  • Man darf natürlich nicht einfach Screenshots von seinem Firefox zum c64 übertragen sondern muss die hinter dem Browser (FF, Chrome, whatever) stehende Engine dergestalt modifizieren das sie eine c64-gerechte Grafik rendert. Bei Links hatte ich das ja schon mal versucht indem ich einen Zeichensatz von GEOS da hereingefrickelt habe. Und an den Stellen, an denen er diesen Zeichensatz auch unskaliert verwendet hat, ist das Ergebnis für meine Begriffe durchaus brauchbar.

    Das ist es, was ich mit einer deutlich aufwendigeres Lösung meine. Einfache Screenshots gehen halt nicht, sondern man muss es C64-optimiert NEU rendern – dann kann es klappen.


    Immerhin könnte man auf diese Weise (also indem man eine leistungstarke Engine auf dem Proxy die Bitmaps rendern lässt) auch leicht mit Frames, Tables, Imagemaps, UTF8 und all dem anderen Mist fertig werden.

    Auf jeden Fall. Ich finde die Lösung ja auch nicht wirklich schlecht. Ganz im Gegenteil – nur habe ich immer noch Bedenken, dass der C64 für die Darstellung komplexer Layouts, selbst als vorgerechnete Bitmaps, vielleicht doch ungeeignet ist. Wenn die Website dank modernem HTML/CSS auch Mobile-tauglich vorliegt, dann sehe auch ich eine Chance, dass 320 Pixel Breite reichen können aber was ist bei Seiten, die unbedingt 3 Frames oder DIV-Spalten nebeneinander darstellen wollen? Neben vertikalen Navigationsbuttons bleibt kaum Platz für Inhalt, dafür ist der C64-Screen zu schmal. Das sind so Situationen, wo ich glaube, dass es besser wäre, nur den Inhalt zu nehmen und das Layout außen vor zu lassen. Aber vielleicht muss man das erstmal ausprobieren und wirklich sehen, um es beurteilen zu können.


    Und das Resultat ließe sich spielend leicht in C64-gerechte Portionen segmentieren

    Da sehe ich auch kein Problem. Vielleicht sollte man bei der Entwicklung schon gleich darauf achten, dass man die C64-spezifischen Einschränkungen nicht fest im Code verankert, damit man das Projekt ohne zu großen Aufwand für andere Client-Rechner (C-128, ST, Specci, Amiga und Co.) erweitern kann.


    Wenn ich mich mal vorrübergehend als potentiellen Entwickler bezeichnen darf: Deine Vorstellung des ASCII-Browsens ist mir schlicht und einfach zu uninteressant um mich noch großartig damit auseinanderzusetzen.

    Erst einmal freu ich mich, dass du Interesse hast, wirklich etwas technisch umzusetzen – egal was. "Meine" Idee (das ist schon mehr als ein ASCII-Browser – Contiki ist ein ASCII-Browser) entsprang dem Gedanken, dem C64 und dem potentiellen Entwickler nicht zuviel zumuten zu wollen. Wenn ein Entwickler mehr will, dann will ich ihm bestimmt nicht im Wege stehen, auch wenn ich ab zu zu meine Bedenken äußern sollte.


    Wenn ich für das Projekt schon nicht bezahlt werde dann muss es doch zumindest für mich selber irgendwie interessant sein, denn ansonsten verbringe ich meine Freizeit anderweitig. Eine grafische Darstellung von Webseiten auf dem c64 (und ähnlichen Devices) finde ich hingegen (im Augenblick noch) interessant, da es eine neue Herausforderung darstellt.

    Was immer dich interessiert: Wenn du Chance für eine Umsetzung siehst, dann ran an den Speck.


    das es ja schon einen massiven Usecase abbildet wenn man Forum64, CSDB, Gamebase etc. handhaben könnte. Ich weiss gerade leider nicht mehr wer das war, aber ich möchte ihm zustimmen. Wenn man mit einem c64 nicht bei Amazon einkaufen oder sich mit google maps die Landschaft angucken kann, dann wäre das für mich völlig Latte. Das würde ich ohnehin nicht am c64 machen wollen.

    Den 2. Teil habe ich ja genau so auch gesagt: Es geht um Info-Seiten, nicht um Einkaufen, Videos gucken oder Werbeseiten von Unternehmen. Allerdings stimme ich dem ersten Teil nicht zu, dass man die Betrachtung nur auf 3 – 10 Domains einschränken sollte. Selbst 1% des Internets sind etwas ganz anderes, als eine 2-stellige Anzahl von Domains.


    Ich habe das oben verlinkte Paper mal weiterverfolgt und musste dabei feststellen, daß genau das hier angesprochene Problem (WWW auf Devices mit low resources) schon um die Jahrtausendwende ein Thema der Forschung war. Damals ging es um PDAs wie den Palmpilot, welche ja bisweilen noch viel dürftigere grafische Möglichkeiten boten als der c64. Na jedenfalls scheint es damals eine ganze Menge Aufsätze gegeben zu haben die sich mit allen Facetten der Problematik auseinandersetzen (u.a. auch mit der Reduktion/reshaping/reflowing des Contents einer Webseite). Keine Ahnung inwieweit die damaligen Erkenntnisse heute noch praxistauglich sind, doch diese Aufsätze stellen für uns nun freilich eine Fundgrube des Wissens dar.

    Ja, natürlich ist der Ansatz nicht neu. Wir haben hier im Laufe des Threads sicher 2 bis 3 Links zu (Web-Reduzierungs-)Projekten verlinkt, die schon Jahre zurückliegen. Was ich aber immer dazu gesagt habe, ist meine (professionelle) Erkenntnis, dass es heute einfacher als damals ist, Webseiten auf ihre Inhalte zu reduzieren. Ob das allerdings auch noch stimmt, wenn man das Layout auch übernehmen will, kann ich nicht wirklich sagen. Bei Mobil-tauglichen Seiten wahrscheinlich schon, bei Desktop-Designs, die heutzutage oft von mindestens 1280 Pixel Breite ausgehen, kann es vielleicht ganz schön wiggelig werden.


    Ja nun, also ich zähle jetzt mal Retrofan und mich selbst in die Gruppe derjenigen, die sich auf den Weg machen wollen um dem C64 das WWW beizubringen. Wo auch immer wir am Ende landen.

    Wäre schön, wenn sich noch andere unserem konstruktiven Ansatz anschließen würden. Man kann ja immer gerne Kritik üben – aber man sollte doch zusehen, dass man mit der Kritik versucht, das Projekt zu verbessern und nicht, es zu verhindern.


    Naja, also hier jedenfalls die allererste veröffentliche Note des Writers. Seid stolz, das ihr diesem Augenblick - als erste Menschen überhaupt - beiwohnen dürft!

    Ja, so mag ich Bitmap-Scrolling. ( Alex: Vergiss meinen Wunsch nach einer Hires-Bitmap-Scrolling-Demo, hat sich erledigt.) ;) Klar, wenn man den Text erst noch rendern müsste (was bei deiner Idee nicht vonnöten ist), dann sähe es nochmal ganz anders aus – aber es flitzt doch viel schneller über den Screen, als viele es für möglich halten würden, die nur an GEOS denken, wenn sie "Hires-Bitmap" hören.

  • Die Idee mit dem Raspberry Pi als Proxy und "Modem" bzw Wifi/LAN-Interface kam mir auch schon... aber keine Ahnung wie das in der Community ankommen wuerde (wirkt schnell so, als wuerde das Raspberry Pi die eigentliche Arbeit machen - was ja zum Teil auch der Fall waere).

  • Eigene Begeisterung für so ein Projekt ist wohl unverzichtbar. Und wenn Retrofan das nicht als sein Projekt sieht, bei dem er peitsche schwingend diktiert was zu machen ist, dann liegt es wohl an Dir, als (vorrübergehend) potentiellen Entwickler, das ganze nach Deinem Geschmack zu formen.

    Ich hatte schon an früherer Stelle gesagt, dass ich mich auf Wunsch des oder der Entwickler(s) auch ganz raushalten kann. Ich sehe das nicht als "mein" Projekt. Wenn ich mal von "meinem" Ansatz gesprochen habe, dann nur als Zusammenfassung dessen, was ich an Vorstellungen geäußert habe. Das einzige, was ich möchte, ist, dass der C64 in die Lage versetzt wird, am Web-Geschehen teilzunehmen. Und zwar vor allem, weil es jetzt geht: Die Zeiten stehen günstig, preiswerte LAN-Hardware zu entwickeln und die Web-Techniken machen auch mehr möglich als noch zur Jahrtausend-Wende.


    Als einfaches HTML meinte ich eben eben auch gerade die Frames, Bildmenüs und Tabellen. Und ich vermute, dass wir bei Tabellen das eine oder andere mal nur Schrott bekommen.

    Wenn ich von einfachem HTML sprach meinte ich eher Seiten, wie Tim Berners-Lee auf seinem Ur-Server liegen hat. Frames und Bildmenüs haben ja Leute verwendet, die Inhalte grafisch aufpeppen wollten. Und Tabellen wurden ursprünglich für Excel-ähnliche Darstellungen erdacht und nicht, um ganze Seitenlayouts zu bauen. Man hat sie dafür missbraucht, weil es nichts anderes zum Gestalten gab.


    Aber das gilt vermutlich generell für Tabellen, vielleicht noch mehr für richtige Tabellen.

    Da kann man durchaus unterscheiden: Tabellen, die Daten übersichtlich darstellen sollen, könnte man noch recht gut retten, indem man der Ausgabe-"Sprache" (wenn ich bei meinem Konzept bleiben dürfte) Tabulatoren beibringen würde. Bei (unsichtbaren) Layout-Tabellen wird das aber nicht viel helfen, weil einfach nach Auflösung der Tabellen nicht mehr zu erkennen ist, was semantisch zusammengehört. Da können auch mal abwechselnd Textabsätze und Elemente der Navigationsleiste erscheinen. Inhalte, die nebeneinander stehen, müssen nicht zwingend zusammengehören. Das ist bei DIVs meistens anders gelöst, weil die Logik ganz anders ist.


    Mein Enthusiasmus reicht gerade nur soweit das ich mich näher in das Thema einlesen mag. Ein produktives Release strebe ich derzeit nicht an, sorry.

    Das ist zwar schade aber ich nehme jeden Strohhalm. ;)


    Und da Retrofan und ich zwar am gleichen Strick ziehen, aber in unterschiedliche Richtungen

    ich würde nicht sagen, dass die Richtungen 180° auseinander liegen, eher so 25°. ;)


    wäre es sicher sehr sachdienlich wenn sich weitere Entwickler fänden.

    Da wäre ich natürlich auch für. Schon alleine den Proxy und den Browser könnte man gut von einander trennen, da komplett unterschiedliche Sprachen dafür verwendet werden.


    Und da selbst im Forum64 die Begeisterung für einen Webbrowser auf dem c64 bislang.. naja, eher verhalten war spielt der Aufwand (für mich) eine umso größere Rolle.

    Naja. Erst einmal liegt dieser Thread (z.Z. noch) in einem sehr allgemeinen Bereich des Forums (sonstige Homecomputer), den viele gar nicht ansteuern werden. Dann werden viele sehr skeptisch sein, dass so ein Unterfangen überhaupt funktionieren könnte. Und manchem ist es vielleicht, solange nichts existiert, auch viel zu technisch/theoretisch. Ein fertiger Browser würde ganz andere Gruppen ansprechen als eine Diskussion über die Machbarkeit von Browsern.


    Wie viele Leute nutzen IE, FF, Chrome, Safari und Co. und wie viele interessiert das Thema an sich? – die Mehrheit will sowas einfach nutzen und nicht darüber quatschen.


    Und trotzdem haben sich hier eine Menge User zum Thema positiv geäußert, manche vielleicht nur einmal (toll, will ich haben, wenn's fertig ist) aber dennoch ist es kein Thema, das wenig Resonanz erfährt.

    In einem anderen Thread hier im Forum geht es gerade um ein Wifi-Modem für $50. Ist ja auch fein. Aber für das gleiche - oder weniger - Geld kann man auch einen Raspi (0W) o.Ä. an den c64 anflanschen, der dann die gesamt Kommunikation mit dem Internet übernimmt, die Webseiten rendert und anschließend als Bitmap mitsamt Metainformationen in den c64 pumpt. Dabei bleibt vielleicht das Gefühl das ein c64 alles kann auf der Strecke, aber zweckmäßig wäre es allemal:

    Klar, man kann einen Raspi so ziemlich für alles benutzen. Und die Akzeptanz für einen Raspi als Surf-Unterstützung wäre sicherlich unterschiedlich. Manche stören sich ja auch nicht daran, dass ein Turbo-Chameleon den echten C64 zum Terminal macht und ihn komplett nachbildet. Und andere finden genau das eine Stufe zuviel auf der Leiter der Machbarkeit. Ich sehe es so: Wenn man einen Raspi zum Herunter rechnen nutzt, warum packt man da dann nicht gleich noch VICE dazu – dann braucht man diese hässliche braune Kiste nicht mehr als Tastatur-Ersatz davor stehen zu haben. ;)


    Aber anderen könnte die Idee gefallen. Und auch ich bin nicht unabgeneigt, wenn es die einzige Lösung wäre, die ich angeboten bekäme. Ich hatte ja schon mal die ganzen Optionen sortiert und da war "Raspi" auf Platz 2 hinter dem öffentlichen Proxy.


    Kurzum: Von der Funktionalität und vom Arbeitsaufwand her fänd ich diese Option durchaus interessant. Aber ich fürchte das dann selbst Retrofan abspringt

    Was heißt "abspringt"? ich würde es nutzen – aber ich finde den Ansatz eher unsexy und langweilig. Klar, mit einem Raspi kann man quasi alles machen, was man will, das weiß jeder. Und ein C64 kann ein Terminal sein, auch das weiß jeder. Mir geht es mit diesem Ansatz wie dir mit dem "ASCII"-Browser.


    Und ja, die Scheibchenweise Übertragung einer Bitmap (+Metainformationen) halte ich durchaus für eine praktikable Option.

    Ich auch, wobei dann natürlich die Leistungsfähigkeit der Datenübertragung der wichtigste Faktor wird. Ich hatte ja grob überschlagen, dass bei 9600 Baud eine C64-Bitmap rund 8 Sekunden brauchen würde. Mit Zusatzinfos (Imagemap für Links ...) sind es vielleicht 10 Sekunden. Und das bei jedem Weiterschalten (sofern es nicht im Hintergrund geschieht). 10 Sekunden können schon ganz schön lang sein, wenn man auf die Darstellung wartet. Es müssten also schnellere Übertragungswege her und die scheint es ja zukünftig zu geben. Aber Bestandshardware (RR-Net...) wäre nicht schneller, oder?

  • Aber Bestandshardware (RR-Net...) wäre nicht schneller, oder?

    Wie bereits geschrieben, das "Comet" Modem von Goog (www.commodoreserver.com) schafft 38,4 baud Datenrate. Es läuft bei mir problemlos.


    Zu der Variante den Proxy auf einem lokalen Raspi zu betreiben: Im Grunde arbeitet das Wifi-Modem von Jammingsignal ähnlich. Da läuft ein Arduino drauf, er baut die Internetverbindung auf agiert als Master und über ein Terminalprogramm auf dem C64 kann man sich dann einloggen. Ich benutze es um bbs zu besuchen. Da man es in den Userport steckt, sehe ich da weniger das Problem, dass es nicht mehr das "pure" C64-Feeling ist. Im Grunde ist es egal, ob der Proxy die Arbeit irgendwo im Netz macht oder hinten am C64 dransteckt. Der C64 wird ja nicht emuliert.