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

letzter Beitrag von emulaThor am

Webbrowser für 8-Bit-Rechner

  • Gedankenaustausch auf Textbasis


    Eigentlich das Gusto jeden Forums ;)


    Wieder wegkommen vom Klickibunti wäre sicher dem Informationsgehalt dienlich :dafuer:


    Die bisherigen Webbrowser Lösungen am C64 sind ja eher arg bescheiden:

    • Singular Browser
      unterstützt zwar 80-Zeichen und ist recht flott, hat aber noch keine funktionierende Maussteuerung, Links anklicken unmöglich
    • Geos-Lösungen
      Wozu erst ein träges GUI laden, wo doch jedes Quäntchen Ressource für das Browsen verwendet werden könnte?
    • Contiki
      ansatzweise modular und viel Raum nach oben, aber derzeit sehr spartanisch


    Andere Lösungen kenne ich gerade nicht. Erprobt haben wir sie im C64 Club Berlin schon öffentlich.


    Die open-Border Funktion wäre auch für die Steuerung denkbar (vor, zurück, top, bottom, home...)
    aber eine komplett Icon-freie Bedienung per Tastatur wäre der Darstellung (Fullscreen) dienlich.,


    Wenn man doch nur wünschen dürfte ;)

  • Ich hatte laut überlegt, ob man nicht so etwas wie Tapatalk machen könnte.


    Das wäre auch ein Ansatz, der sinnvoll wäre. Allerdings wäre das deutlich spezieller, gleichzeitig aber auch überschaubarer, was die Anforderungen angeht.


    aber eine komplett Icon-freie Bedienung per Tastatur wäre der Darstellung (Fullscreen) dienlich.,


    Es gehen momentan ja nur 2 Char-Reihen verloren, die gleichzeitig auch für die URL (und auch für Links) genutzt werden. Aber man könnte natürlich überlegen, diese Leiste ausblendbar zu machen – auf Wunsch sogar dynamisch, wie bei Mobile-Browsern (beim Runterscrollen ausblenden, beim Hochscrollen einblenden). Und die Unterstützung von Tastatur-Kürzeln versteht sich von selbst.


    Nehmen wir mal an, so ein Proxy existiert ausserhalb der eignenen vier Wände und anonimisiert die Clientzugriffe. Was dann? Es dauert nicht lange, bis vielleicht jemand was Dummes macht und die Behörden dann die Clientdaten rausgerückt haben wollen.


    Das kann natürlich bei jedem Zugangs-Server/Provider passieren. Aber Daten, die man nicht hat/speichert, kann man auch nicht herausgeben – also sollte man nach einer Session die dafür nötigen Daten einfach wieder löschen – wir müssen ja keine Rechnungen schreiben ;) . Stände der Proxy im Ausland, würde auch die hiesige Vorratsdatenspeicherung nicht greifen, wenn sie käme.


    Ausserdem wird man den Proxy deshalb eher auf einem der eigenen PCs laufen lassen und der 8-Bitter wird die Daten aus dem eigenen, lokalen Netzwerk bekommen.


    Das sollte jeder machen können, wie er mag. Es sollte öffentlich zugängliche Proxys geben aber wer mag, soll die Software auch auf dem heimischen PC/Server installieren können. So hätte man das Beste aus beiden Welten (öffentlich und privat).


    Dein Ansatz mit dem Proxy ist vermutlich unvermeidbar, wenn man ein einigermassen erträgliches Datenhandling für die kleinen 8-Bitter hinkriegen möchte. Es wäre auch nicht ganz so einfach, einen generischen Ansatz zu wählen, mit dem man eben nicht nur den C64 sondern auch andere 8-Bitter damit speisen könnte.


    Ich denke, ein allgemein gültiger Ansatz wäre nicht viel schwerer zu realisieren, als eine proprietäre C64-Lösung. Man definiert halt Standards, die der Browser beherrschen muss, um mitspielen zu können. Und man kann das (je nach Hardware-Fähigkeiten) durchaus gestaffelt tun.


    Wobei: So ein Markdown-Proxy wäre ja nicht auf 8-Bit limitiert: Man könnte man damit auch eine Amiga/AtariST/Win/Mac/iOS/Android etc. Version des Clients programmieren!


    Natürlich. Oder auch eine für alte Palms oder andere schwachbrüstige Internet-taugliche Devices. Der Client-Browser stellt sich dem Proxy vor und es wird ausgehandelt, was der Client kann, z.B. was die Farbtiefe von Bildern angeht, wie "groß" der Screen ist und wie viel RAM zur Verfügung steht. Dann kann der Proxy alles so aufbereiten, wie es für das Zielsystem am Günstigsten ist. Schlimmstenfalls könnte der Proxy einfach vorgerenderte Bitmaps rüberschicken – dann braucht der Client nur 1-Bit-Bilder anzeigen können und gar keine Intelligenz darüber hinaus (Markdown-Interpreter mit Umbruchkontrolle, Fonts ...) besitzen.

  • Natürlich. Oder auch eine für alte Palms oder andere schwachbrüstige Internet-taugliche Devices. Der Client-Browser stellt sich dem Proxy vor und es wird ausgehandelt, was der Client kann, z.B. was die Farbtiefe von Bildern angeht oder wie "groß" der Screen ist. Dann kann der Proxy alles so aufbereiten, wie es für das Zielsystem am Günstigsten ist. Schlimmstenfalls könnte der Proxy einfach vorgerenderte Bitmaps rüberschicken – dann braucht der Client nur 1-Bit-Bilder anzeigen können und gar keine Intelligenz darüber hinaus (Markdown-Interpreter mit Umbruchkontrolle, Fonts ...) besitzen.


    Ernst gemeinte Antwort:
    Dann brauch man aber noch die Info, wo sich Links zum anklicken befinden.


    Nur mal so aus Jux:
    Dann will ich aber auch YouTube haben! Da werden die Videos dann einfach on the fly in Nuvies gewandelt! :D



    Das wäre auch ein Ansatz, der sinnvoll wäre. Allerdings wäre das deutlich spezieller, gleichzeitig aber auch überschaubarer, was die Anforderungen angeht.


    Mit einer passenden API für Foren (keine Ahnung, ob man die von Tapatalk nutzen kann) wäre die Umsetzung für 8-Bitter recht einfach. Und ich fänd es cool dieses Forum mit einem C64 zu nutzen. Ja, es ist spezieller aber an Tapatalk sieht man, dass ein Tool nur für Foren selbst auf deutlich potenteren Geräten genutzt wird. Das wäre ein Inet Programm für 8-Bitter, was man wirklich nutzen könnte und wo man nur geringe Nachteile in Kauf nehmen müsste.

  • Auch wenn es wahrscheinlich nie zu einer Realisierung kommt: Hier ist ein leicht verbesserter Browser-Mockup-Screen: Im neuen iOS7- bzw. Material-Design mit etwas mehr Platz für Inhalt. Dank geöffneter Border kann man mit dem Seiteninhalt direkt bis zum Rand gehen. Foto rausgenommen und besser lesbare Schrift verwendet.



    Schade, dass sich anscheinend keiner findet, der die Idee eines 8-Bit-Web-Proxies so bestechend findet wie ich und gleichzeitig in der Lage wäre, sowas in Ansätzen zu entwickeln.


    Na ich finde die Idee schon super. Vor allem, da dank der vielen Netzwerkkarten ein C64 ins Internet kann. Und spaßig wäre das auf jeden Fall. Muss mir mal ein paar Gedanken dazu machen.


    P.S.: cooles Design!

  • Dann brauch man aber noch die Info, wo sich Links zum anklicken befinden.


    Das könnte man ähnlich den alten Imagemaps lösen. Also klickbare Rechtecke auf der Grafik definieren.


    Aber das soll nicht unbedingt das Ziel sein. Mir schwebt eher ein minimalistischer Parser vor, der Markdown, Hyperlinks, rudimentäre Grafik und Formulare (ohne Forms keine Suche und keine Foren) versteht. Vielleicht kann man sich sogar an dem alten WAP-Standard orientieren, dann wäre der Proxy eine Art Web2Wap-Converter. Es kommt halt darauf an, dass die wichtigsten Sachen möglichst kompakt zum Client kommen. (Mein altes WAP-Buch wieder rauskram)


    Na ich finde die Idee schon super. Vor allem, da dank der vielen Netzwerkkarten ein C64 ins Internet kann


    Mich interessiert besonders die angedachte Lösung von Matze79: "Userport Stecker, RS232 (MAX2323) Pegelwandler Modul und ESP8266 Wlan Modul. ~ So um die 15 Euro + paar Käbelchen und 3,3V Spannungsquelle." Wenn man wirklich für unter 20 € den C64 ins WLAN (und damit ins Internet) bekäme, dann würden das sich noch deutlich mehr Leute nutzen.


    P.S.: cooles Design!


    Danke. Es soll ja auch Spaß machen, mit den C64 ins Internet zu gehen. Da kommt es schon auf den Browser an. Ich finde auch, dass man so einen Browser schnell vom EasyFlash o.ä. starten können soll, damit man sofort los-surfen kann – und nicht erst noch irgendein GUI starten und dort herumklicken muss.

  • Nicht, dass das falsch verstanden wird: MEINE Intention war niemals, eine Alternative für Firefox/Chrome/aktueller-PC zu entwerfen. Es geht mir lediglich darum, zu eruieren, wie schnell/langsam/tauglich/erstaunlich ein webbrowsender C64/C128/Specci/AppleII/Nameyour8bitcomputer sein könnte. Mich interessiert, wie man möglichst viele Daten vom 8-Bit-System weghalten kann und die "Intelligenz" auslagert, sodass der kleine Rechner möglichst wenig mit der Interpretation der Seiten zu tun hat und trotzdem das ganze WWW im Zugriff hat.


    Klingt nach einem interessanten Plugin für einen bestehenden Webbrowser der wirklich nur sinnvollen Text parst und das über eine einfache Schnittstelle weitergibt.
    Man steuert einen Webbrowser auf einer anderen Machine fern.


    Mich interessiert besonders die angedachte Lösung von Matze79: "Userport Stecker, RS232 (MAX2323) Pegelwandler Modul und ESP8266 Wlan Modul. ~ So um die 15 Euro + paar Käbelchen und 3,3V Spannungsquelle." Wenn man wirklich für unter 20 € den C64 ins WLAN (und damit ins Internet) bekäme, dann würden das sich noch deutlich mehr Leute nutzen.


    Zu aufwendig. Man hat ja kaum genug Ram um eine reduzierten TCP/IP Stack unter zu bringen. Bei so eher dynamischen Dingen wie Webbrowserei brauch ich aber viel direkt adressierbaren Speicher. Davon hab ich aber nicht mal 64k frei.

  • der wirklich nur sinnvollen Text parst


    Dann würde vom Forum hier aber nur noch die Hälfte überbleiben... und es wäre nur noch halb so interessant :whistling:

  • Klingt nach einem interessanten Plugin für einen bestehenden Webbrowser der wirklich nur sinnvollen Text parst und das über eine einfache Schnittstelle weitergibt.


    Das hat mein Browser schon lange eingebaut. Bei Safari steht neben der Adresszeile der Button "Reader", welcher aktiv wird, wenn der Browser eindeutig erkennt, was purer Inhalt und was Beiwerk ist. Klickt man darauf, bekommt man reinen Text ohne Werbung etc. Das, was man da sieht, könnte in etwa das sein, was der angedachte C64-Browser anzeigt.


    Zu aufwendig. Man hat ja kaum genug Ram um eine reduzierten TCP/IP Stack unter zu bringen.


    Wie jetzt? Ein Problem? Ein Wunsch (bzw. Hoffnung) von mir war ja, dass man eine preiswerte Lösung für einen C64-Intenetzugang bekommen kann. Mehr als eine simple Verbindung zum Internet muss das Teil ja nicht aufbauen (also TCP/IP), den Rest erledigen Browser und Proxy – oder verstehen wir uns hier falsch?

  • TCP/IP ist leider alles andere als simpel, erträglich wirds erst auf Telnet-Ebene (was man natürlich vom 'Groß´rechner' via RS232 in den 64er leiten kann)


    Webseiten waren mal problemlos, einfach alle Tags ignorieren die kein IMG SRC oder A HREF sind. Heutzutage bekommt man da aber allenfalls ne Meldung man solle den neuesten XY-Browser installieren.


    Bliebe als letzte Möglichkeit, den Browser-Output mit der Einstellung 'Webseiten-Stil: keiner' weiterzuleiten. Oder das alte Opera-User-Script für Pseudo-C64-Stil wiederzubeleben.


    (MATRIX-Fans telnetten in eine Linux-Box und surfen im HTML-Quelltext...)

  • Wie ist/war es eigentlich mit WAP: Musste man da den Content extra neu designen oder wurde das "automatisch" generiert, eben mit einer Art Proxy?
    Wenn Letzteres der Fall ist/war, könnte man den WAP Content eher so an die 8-Bitter anzeigen/weiterleiten lassen? Wobei das mit den Bildern (und Videos, haha) dann noch nicht gelöst ist.

  • Für WAP musste man extra Seiten in WML anstelle von HTML schreiben und für "Bilder" hatte man das WBMP format (echt S/W keine Graustufen :D ). Extra Proxies gab (gibt?) es aber auch dafür. Da wurde das WML tokenized, damit es die Telefone leichter hatten und die benötigte Bandbreite noch kleiner wurde. Wäre also perfekt für den C64. Selbst die WBMP-Bildchen könnte er darstellen zur Not per PETSCII.
    Ich weiß aber nicht, ob es (noch) frei nutzbare WAP-Proxies gibt und wieviele der eh schon damals seltenen WML-Seiten noch existieren. Hat hier noch jemand ein altes WAP 1.2 Handy im Einsatz und kann testen, ob es die WAP-Seiten von z.B. Ebay noch gibt. Mit neueren Handys wird einem bei der Mobilen Seite ja nur dieses XHTML angezeigt.

  • und wieviele der eh schon damals seltenen WML-Seiten noch existieren.


    Das ist halt das Problem. Ich will ja keine 15 Jahre alten Seiten aufrufen können, sondern am aktuellen Web-Geschehen teilnehmen. Und (das original) WAP ist halt einfach schon lange tot. Mir ging es darum, zu gucken, was man von der Technik eventuell für unseren angedachten Proxy missbrauchen könnte.


    Für WAP musste man extra Seiten in WML anstelle von HTML schreiben


    Deswegen ist es in der Art, wie es ist/war, für dieses Konzept untauglich. Ich suche nach einer universellen Lösung. Aber, wie gesagt, man kann gucken, ob man von dem Sprachschatz etwas gebrauchen kann. Man muss das Rad ja nicht ohne Not neu erfinden. Ich glaube aber, dass man mit Markdown und ein paar selbsterfundenen Tags genauso weit kommt, wie mit WML.


    Webseiten waren mal problemlos, einfach alle Tags ignorieren die kein IMG SRC oder A HREF sind.


    Das sehe ich anders. Gerade heute kann man bei Webseiten den nackten Inhalt viel besser extrahieren. Vor allem, weil die alten Tabellenkonstrukte weggefallen sind und das Design in externe CSS-dateien gepackt wurde. Zudem sind PlugIns (bis auf das sterbende Flash) quasi nicht mehr existent und es wird teilweise an kleine Screens (Smartphones) gedacht. Heutzutage sind die HTML-Seiten deutlich sauberer und auch einfacher runterzubrechen als das früher (Anfang der 2000er Jahre) der Fall war.

  • Ich suche nach einer universellen Lösung.


    Das ist genau das Problem. 8-Bitter können nicht annähernd das darstellen, was heute so auf Webseiten verbrochen wird. Und dazu sind die Seiten auch noch so individuell, dass auch ein Automatisiertes eindampfen alles andere als trivial ist. Den Postings/Texte aus Foren aus einer Datenbank zu holen und für einen 8-Bitter aufzubereiten könnte man schon fast als trivial bezeichenen. Aber "sinnvolle" Informationen aus einer Webseite zu extrahieren, um sie dann (ansprechend/passend) aufzubereiten ... da brauch man schon eine gute KI für. Nicht falsch verstehen! Ich fänd es gut, wenn es so etwas geben würde und wenn es dann auch noch funktioniert aber ich denke, dass es auch wieder nur einen kleinen Teil des Netzes zugänglich macht und das bei einem sehr hohen Aufwand.


    Das sehe ich anders.


    Ich glaube er meint noch ältere Seiten! So aus der Zeit, wo 90% aller Seiten soh aussahen: http://www.x1541.de/
    Ein bisschen vermisse ich die Zeit schon!


    Nach reiflicher überlegung würde ich mich aber gegen die Idee mit dem Übertragen der Inhalte als Bild aussprechen. Texte übertragen und die Darstellung dem Client überlassen, finde ich da doch deutlich besser. Unterschiedliche Clients haben unterschiedliche Auflösung, was man noch dadurch abfackeln kann, dass der Client seine Daten dem Proxy mitteilt und er entsprechend rendert. Aber eine 80- oder 40-Zeichen Darstellung und Großkleinschreibung oder nur Großbuchstaben, unterschiedliche Zeichensätze und all so Zeug könnte man wohl besser auf der Clientseite umsetzen. Wenn schon nur Text, dann wenigstens so, wie man das will! ;)



    Nein, der Rest, der jetzt kommt, ist nicht wirklich ernst gemeint! (Wäre aber extrem witzig, um einen auf dicke Hose zu machen!)


    Die Idee mit Youtube gefällt mir immer besser! So wie Tapatalk für Foren fänd ich ein Tool für YouTube klasse. NUVIE geht nicht aber die Videos in Videostreams mit kleinerer Auflösung und nur 4 Graustufen konvertieren, dass die so wie auf der YouTube-Seite auf einer Seite (Hintergrundbild) für den 8-Bit Rechner eingebettet sind. Wäre das nicht möglich? :D (Ein Mockup wäre klasse! :whistling: )
    Ich würde mir da so eine Auflösung von 80x100x4 mit 12,5 fps für die Multicolour-Auflösung vorstellen. Was für eine Datenrate schafft ein C64 über das RRNet? :D
    Und für Ace gibt es eine Version für YouPorn! ;)

  • Und für Ace gibt es eine Version für YouPorn! ;)


    :thumbsup::juhu:

  • Erinnert sich denn niemand mehr ? - Im Jahr 2003 gab es schon mal einen Ansatz in diese Richtung: CML http://www.lemon64.com/forum/viewtopic.php?t=10129


    Ist damals aber scheinbar auch im Sand verlaufen. Heute stelle ich mir das mit Übersetzung von Standard-Seiten erheblich schwieriger vor: Das Gerüst ist meist nur noch CSS (eckig, praktisch, gut) und funktional werden megabyteweise Javascript zum Client übertragen. Letzteres war 2003 noch einigermaßen verpönt.

  • Aktuell würde das schon viel einfacher gehen. Die Seiten sind ja zum größten Teil in Content und Design (CSS) getrennt. Das JS dient ja meist nur zur Bedienungserleichterung und könnte auch wegfallen. Ein Proxy hätte nicht allzugoße Probleme den ganzen Overhead einfach raus zu lassen und nur die reinen Inhalte weiterzuleiten. Dann ist auch die Größe der ursprunglichen Seite egal.


    Hier gibt es z.B. einen TextBrowser (auch als Proxy nutzbar):
    http://www.labnol.org/internet/google-text-browser/26553/

  • So eine ähnlich Idee hatte ich eben auch schon. Wenn man dann aber eine Seite z.B. mit vielen Div-Layern hat, die sich im Prinzip überall befinden könnten, braucht man doch wieder daraus etwas Layout. Wenn man da einfach den Content filtert, könnte es sehr schwierig werden, daraus noch etwas zu erkennen.

  • So eine ähnlich Idee hatte ich eben auch schon. Wenn man dann aber eine Seite z.B. mit vielen Div-Layern hat, die sich im Prinzip überall befinden könnten, braucht man doch wieder daraus etwas Layout. Wenn man da einfach den Content filter, könnte es sehr schwierig werden, daraus noch etwas zu erkennen.


    Vom Layout wird man sich verabschieden können. Was wohl noch gehen könnte ist, dass man die ULs als Menu erkennt und diese eventuell noch ein wenig layoutet.

  • 8-Bitter können nicht annähernd das darstellen, was heute so auf Webseiten verbrochen wird. Und dazu sind die Seiten auch noch so individuell, dass auch ein Automatisiertes eindampfen alles andere als trivial ist.


    Trivial ist es nicht. Ich sagte ja: wir wollen es, weil es schwer ist – nicht weil es leicht ist. ;) Natürlich kann ein 8-Bitter heutige Seiten nicht darstellen, daher ja der Proxy. Das ist der Dreh- und Angelpunkt.


    Den Postings/Texte aus Foren aus einer Datenbank zu holen und für einen 8-Bitter aufzubereiten könnte man schon fast als trivial bezeichenen.


    Da sind wir uns einig. Aber das bildet halt nur 0,01% des Internets ab. Ich hätte gerne mehr. Die Frage ist halt, ob man das mit dem Proxy-Trick hinbekäme.


    Erinnert sich denn niemand mehr ? - Im Jahr 2003 gab es schon mal einen Ansatz in diese Richtung


    Nein, ich erinnere mich nicht. Aber auch hier scheint die Idee gewesen zu sein (wie bei dem neuen TI-Browser), zusätzlichen Code in eine HTML-Seite einzubetten, der dann von diesem Browser gelesen wird. Das ist ja was ganz anderes als die hier diskutierte Proxy-Technik, die "jede" normale HTML-Seite lesbar machen soll.


    Aktuell würde das schon viel einfacher gehen. Die Seiten sind ja zum größten Teil in Content und Design (CSS) getrennt. Das JS dient ja meist nur zur Bedienungserleichterung und könnte auch wegfallen. Ein Proxy hätte nicht allzugoße Probleme den ganzen Overhead einfach raus zu lassen und nur die reinen Inhalte weiterzuleiten. Dann ist auch die Größe der ursprunglichen Seite egal.


    So sehe ich das ja auch.


    Wenn man dann aber eine Seite z.B. mit vielen Div-Layern hat, die sich im Prinzip überall befinden könnten, braucht man doch wieder daraus etwas Layout.


    Naja, die meisten Divs werden ja "relative" positioniert und liegen somit im normalen Lesefluss. Was also oben im HTML-Text steht, wird auch auf der Seite oben angezeigt, was weiter unten steht, wird auch tiefer angezeigt. Wie gesagt, bei meinen Seiten ist es so, dass wenn man das CSS wegwirft, immer noch die Inhalte in korrekter Reihenfolge auf dem Schirm hat.


    Vom Layout wird man sich verabschieden können. Was wohl noch gehen könnte ist, dass man die ULs als Menu erkennt und diese eventuell noch ein wenig layoutet.


    So ähnlich habe ich mir das auch vorgestellt. In erster Linie wird weggeworfen und dann wird noch ein wenig optimiert. Man könnte den Proxy auch in mehreren Ausbaustufen realisieren. Die erste Version wirft einfach CSS und JS raus, ein spätere versucht bei Seiten, die ein Mobile-CSS für Smartphones anbieten (Stichwort: Responsive Design), dieses zu laden und dann diese Darstellung zu optimieren/konvertieren.


    Sobalds aber mehre Frames werden und Tabs wirds schon komplex


    Tabs haben mit HTML ja nichts zu tun, das ist ein Browser-Feature. Und Frames verwendet man (glücklicherweise) schon lange nicht mehr.