Webbrowser für 8-Bit-Rechner

  • Rotzwald schrieb:

    Wie bereits geschrieben, das "Comet" Modem von Goog (commodoreserver.com) schafft 38,4 baud Datenrate. Es läuft bei mir problemlos.
    Sorry, das Comet schafft 38,4 Kbaud, 38,4 baud wär dann doch lähmend ;)

    Und zur Bitmap-Variante ist noch eine Frage offen, die mich interessieren würde.

    Rotzwald schrieb:

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

    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.
    War doch nicht ganz mein Ernst mit der Peitsche. Ich hatte Dich schon so verstanden, dass Du hier etwas "anschubst", was nicht klar definiert ist. Da Du aber von Anfang an sehr intensiv in diesem Thread steckst und ganz schon 'ne knappe Milliarde Bytes dazu geschrieben hast (oder waren es mehr? :D ), bin ich der Meinung, dass Du vermutlich den Besten Überblick hast. Irgendwo müssen ja erstmal die Fäden zusammenlaufen. Und bis sich jemand anders dazu erklärt die Fäden zu halten, hältst Du sie :D

    Retrofan schrieb:

    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.
    Ich meinte eher Tabellen mit Inhalten, die sich dann tatsächlich schwer in 40-80 Zeichen darstellen lassen. Aber das könnte man zur Not dann auch als Auflistung mit Einrückung o.ä. darstellen.

    Rotzwald schrieb:

    Wie bereits geschrieben, das "Comet" Modem von Goog (commodoreserver.com) schafft 38,4 baud Datenrate. Es läuft bei mir problemlos.
    Wieviel schafft denn der c64 überhaupt?
    carrier lost...
  • @Snear: Den Font habe im TrueType-Format angehängt. Als C64-Font habe ich ihn nicht. Ich verwende ihn in Photoshop für die Mockups, den Wortabstand habe ich dort etwas verringert. Es sind noch nicht alle Sonderzeichen enthalten – aber für die meisten Sachen wird es reichen. Gezeichnet habe ich die beiden Schnitte (normal und bold) mit diesem Webtool.
    Dateien
    • Read-Font.zip

      (9,22 kB, 5 mal heruntergeladen, zuletzt: )
  • Neu

    Rotzwald schrieb:

    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?
    Ich denke schon, dass es mehr als ein Reader sein soll. Links müssen funktionieren, sonst funktioniert das Web nicht. Und Formulare etc. sollten wohl auch funktionieren, sonst wäre außer einer hübschen Optik gegenüber Contiki nichts gewonnen. Formulare müssen übrigens nicht unbedingt dort ausgefüllt werden, wo sie erscheinen. Safari/iPhone stellt z.B. Popup-Menüs, sobald man sie anklickt, ganz anders (Finger-optimierter) dar, als es die Webseite tun würde. Wenn man also vermeiden möchte, in der herunter geladenen Bitmap herumzumalen, dann könnte man für Eingaben auf eine spezielle Ansicht umschalten.

    Rotzwald schrieb:

    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. 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.
    Für mich persönlich macht es schon einen Unterschied, ob der Proxy frei zugänglich im Netz liegt oder jeder seinen eigenen Proxy am C64 stecken hat. Zumal eine Lösung, die speziell für eine C64-Schnittstelle angepasst wurde, wenig universell ist. Mein Begehr wäre ja, Das Web allen schwachbrüstigen Hardwares zugänglich zu machen und nicht nur dem C64.

    Außerdem hege ich die Hoffnung, dass ein frei zugänglicher Proxy einen gewissen Reiz ausüben würde, ihn auch zu nutzen. Wenn dann noch sehr günstige Hardware angeboten würde (Servant64 kostete was bei 20 €), wäre es für viele quasi ein Nobrainer, den Proxy zu nutzen und mal mit C64 und Co. ins Netz zu gehen. Auch die Bestands-Ethernet-Lösungen, die in 1541U und TC64 eingebaut sind (oder Lösungen für ganz andere Computer), wären mit einem externen Proxy nutzbar, während ein weiteres "Modul" diese LAN-Hardware unnütz erscheinen lassen würde.

    Rotzwald schrieb:

    das Comet schafft 38,4 Kbaud
    Sorry, ich hatte mich da falsch erinnert und dachte kurz, nur der Nachfolger hätte diese Specs. Interessant wäre halt, wie viel davon der C64 wirklich verarbeiten kann (also, wäre die Anbindung der Flaschenhals oder das Endgerät?) und wie schnell andere, verbreitetere, Lösungen so sind. Wenn man jetzt wirklich auf Bitmap-Übertragung setzen sollte, dann wäre das ja schon interessant zu wissen.

    Und mir ist nachträglich klarer geworden, dass Rapid Eraser nicht erst eine ganze C64-Bildschirmseite übertragen möchte, sondern die angesprochenen "Streifen" kleiner sind als ein Screen – und damit auch die Wartezeiten kürzer als von mir gedacht. Mein READ-Zeichensatz ist ja für 8 Pixel Zeilenabstand optimiert und so könnte man z.B. in 5 Schüben zu je 5 Text-Zeilen (40 Pixelzeilen) den ersten Screen aufbauen und dann soviel nachschieben, wie der Speicher verträgt.

    Chagizzz schrieb:

    Und bis sich jemand anders dazu erklärt die Fäden zu halten, hältst Du sie
    Kann ich gerne machen, solange sich der/die Entwickler nicht daran stößt/stoßen. ich bin mal gespannt, ob sich Rapid Eraser schon in sein "Programmier-Kämmerchen" zurückgezogen hat und codetechnisch was ausheckt.
  • Neu

    ZeHa schrieb:

    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).

    Und es hat ja auch durchaus seinen Sinn, das man intelligente HW baut. Hat Commodore selber schon vor Jahrzehnten gemacht. :)
    Und da wir ja nicht auf jeden Euro achten müssen möchte ich meinen: Je weniger Arbeit der C64 übernehmen muss desto besser.

    Retrofan schrieb:


    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. ;)

    VICE kann derzeit sicherlich viel HW "unnütz" machen, z.B. alle Arten von Massenspeichern. Doch einen C64-Browser bekommst du dadurch trotzdem nicht. ;)
    Den RasPi hatte ich aber auch eher als plakatives Beispiel genannt. Dennoch, ich halte es nicht für angebracht von vornherein unnötige Constraints aufstellen zu wollen. Beispielsweise das Markdown verwendet werden und das der C64 die Seite selber rendern soll. Beides wird für den Anwender ohnehin völlig transparent sein, und da wir selber (oder ich zumindest) noch immer nicht wissen wie praktikabel diese Wünsche in der Praxis sein werden möchte ich mich da bislang noch auf nichts festlegen. Diese Entscheidungen würde ich ersteinmal vertagen wollen bis wir klarer sehen.

    Retrofan schrieb:

    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.

    Naja, 1KB Bitmapdaten pro Sekunde sind ja ca. 3 Zeilen à 8 Pixel. Da kommen die Texte doch schon schneller hereingerauscht als du sie lesen kannst. Warst wohl nie mit 300 Baud unterwegs, du Sohn der Ungeduld. ;)
    Was man noch erwähnen sollte: Markdown u.ä. eignen sich leider nicht für ein partielles Rendering. Falls so ein MD-Dokument größer ist als der Speicher der Clients dann reicht es nicht wenn der Client nur den nächsten Abschnitt des Dokuments vom Server anfordert; er müsste zum Weiterblättern wohl das Dokument von Anfang an neu beim Server anfordern, um den bereits gesehenen Teil zu interpretieren und dann wegzuwerfen. Das kann sicher auch leicht einige Sekunden extra in Anspruch nehmen.
    Weiss jemand zufällig wie Contiki das handhabt?

    Retrofan schrieb:

    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?

    Ehrlich gesagt habe ich nicht den blassesten Schimmer wie die Kommunikation in Netzwerken am C64 funktioniert. Ich weiss nur das ich damals ein Modem (natüüürlich vom Schwarz-Schilling abgesegnet...) am C64 und an der Telefonbuchse angeschlossen und mich dann per TelNr. in irgendeine Mailbox eingewählt habe. Wie läuft das denn heute? Braucht man immer noch dedizierte Rechner in die man sich mit so geringen Baudraten einwählen kann oder kann man einen 08/15 DSL-Anschluss verwenden? Wo würden dann solche Späße wie der TCP/IP oder DHCP gehandelt?

    Rotzwald schrieb:


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

    Klaro sollen Links, Eingabezeilen usw. trotzdem möglich sein. Die nötigen Infos dazu würden halt in den Metainformationen stecken welche zusätzlich zum Content der Seite übertragen werden.

    Retrofan schrieb:


    Kann ich gerne machen, solange sich der/die Entwickler nicht daran stößt/stoßen. ich bin mal gespannt, ob sich Rapid Eraser schon in sein "Programmier-Kämmerchen" zurückgezogen hat und codetechnisch was ausheckt.

    Sorry, nein, noch lange nicht, dazu ist die Aufgabe noch viel zu schwammig. Lass mal überlegen, wie könnte man anfangen
    - die htmlseite "segmentieren" (aber nach welchen Kriterien?)
    - ggf. Menus/Formulare/Bilder erkennen und separat behandeln
    - unerwünschte Segmente herauswerfen (woran erkennt man die?)
    - in den verbleibenden Segmenten nicht benötigtes/gewünschtes Html/CSS (woran erkennt man das?) löschen
    - ggf. die verbleibenden Segmente vereinfachen (z.B. Layout zurechtrücken)
    - das Dokument in ein noch zu definierendes Ausgabeformat, z.B. Markdown, wandeln (wie sieht die Abbildung von HTML auf Markdown aus?)

    Unabhängig davon:
    - wie kommuniziert der C64 mit dem Server? Über ein HTTP-Subset?
  • Neu

    Rapid Eraser schrieb:

    Beispielsweise das Markdown verwendet werden und das der C64 die Seite selber rendern soll.
    Markdown: Siehe unten. Rendern am C64: Dafür.

    Rapid Eraser schrieb:

    Naja, 1KB Bitmapdaten pro Sekunde sind ja ca. 3 Zeilen à 8 Pixel. Da kommen die Texte doch schon schneller hereingerauscht als du sie lesen kannst.
    Von den Bitmapdaten würde ich völlig weg gehen, da es ja auch plattformübergreifend sein/werden soll. Das geht dann ja einfach nicht. Dass die Daten 'on-the-fly' kommen (können), sollte selbst ja kein Problem darstellen.

    Rapid Eraser schrieb:

    Was man noch erwähnen sollte: Markdown u.ä. eignen sich leider nicht für ein partielles Rendering. Falls so ein MD-Dokument größer ist als der Speicher der Clients dann reicht es nicht wenn der Client nur den nächsten Abschnitt des Dokuments vom Server anfordert; er müsste zum Weiterblättern wohl das Dokument von Anfang an neu beim Server anfordern, um den bereits gesehenen Teil zu interpretieren und dann wegzuwerfen. Das kann sicher auch leicht einige Sekunden extra in Anspruch nehmen.
    Markdown ist ja schon schön klein, muss dann aber komplett 'durchgescannt' werden, um HTML (oder eben das 8-Bit-Browserformat) zu erzeugen. Markdown ist halt nur freundlich für (reine) Text-Schreiber ausgelegt (so wie ich das verstanden habe). Es ist doch wohl nur eine reine Text-Datei. Es ist ja eben noch absolut NULL 'Code' enthalten (für die Formatierung etc.). Eben erst nach der Konvertierung zu HTML. Dann ist es aber eh wieder unbrauchbar. Gibt es denn (überhaupt) auch einen Konverter HTML -> Markdown? Keine Ahnung. Ich denke nicht. Geht wohl auch gar nicht und bringt ja auch eh nix.

    Rapid Eraser schrieb:

    - das Dokument in ein noch zu definierendes Ausgabeformat, z.B. Markdown, wandeln (wie sieht die Abbildung von HTML auf Markdown aus?)
    Ach..., siehe davor.
    Read'n'Blast my jump'n'stop-text-sprite-scroller Select A Move

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?
  • Neu

    Rapid Eraser schrieb:

    Und es hat ja auch durchaus seinen Sinn, das man intelligente HW baut. Hat Commodore selber schon vor Jahrzehnten gemacht.
    Und da wir ja nicht auf jeden Euro achten müssen möchte ich meinen: Je weniger Arbeit der C64 übernehmen muss desto besser.
    Beim letzten Punkt bin ich ja voll bei dir, sonst hätte ich ja nicht von Anfang an die Proxy-Idee favorisiert. Ob man dafür propritäre Hardware (neben einem Netzwerkanschluss) benötigt, muss erst noch geklärt werden. Und das mit dem Euro würde ich gerne im Auge behalten, denn ich wäre schon dafür den Gesamtaufwand (inkl. Kosten) – und damit die Einstiegsschwelle – möglichst gering zu halten. Sollte es z.B. 100 € kosten, mit dem C64 ins Web zu kommen, dann muss man den Usern schon was bieten, sonst lassen sie es bleiben. Bei 20 € würden viele sagen: Komm, das probieren wir einfach mal aus.

    Rapid Eraser schrieb:

    VICE kann derzeit sicherlich viel HW "unnütz" machen, z.B. alle Arten von Massenspeichern. Doch einen C64-Browser bekommst du dadurch trotzdem nicht.
    Ich meinte eher, dass VICE den kompletten C64 ersetzen könnte. Wenn eh schon der ganze Browser-Job auf dem Raspi gemacht wird, was hindert einen daran, auch noch den C64 mittels VICE selbst darauf laufen zu lassen? – Dann würde man keine C64-Hardware mehr benötigen, aber dann wäre auch das Projekt selber ad absurdum geführt. ich wollte damit aufzeigen, dass man nicht beliebig viel Intelligenz außerhalb des c64 realisieren sollte, weil irgendwann dadurch das Projekt "kippt". Der C64 sollte meiner Meinung nach kein komplett dummes Terminal werden. Andere können das aber gerne anders sehen.

    Rapid Eraser schrieb:

    Den RasPi hatte ich aber auch eher als plakatives Beispiel genannt. Dennoch, ich halte es nicht für angebracht von vornherein unnötige Constraints aufstellen zu wollen. Beispielsweise das Markdown verwendet werden und das der C64 die Seite selber rendern soll.
    Ich will keine Axiome festlegen, meine Vorschläge sind bitte auch nur als solche zu verstehen – es sind keine festen Vorgaben. ich bin froh, wenn in alle Richtungen gedacht wird, bevor man anfängt, irgendwas zu programmieren.

    Rapid Eraser schrieb:

    da wir selber (oder ich zumindest) noch immer nicht wissen wie praktikabel diese Wünsche in der Praxis sein werden möchte ich mich da bislang noch auf nichts festlegen. Diese Entscheidungen würde ich ersteinmal vertagen wollen bis wir klarer sehen.
    Da bin ich deiner Meinung.

    Rapid Eraser schrieb:

    Naja, 1KB Bitmapdaten pro Sekunde sind ja ca. 3 Zeilen à 8 Pixel. Da kommen die Texte doch schon schneller hereingerauscht als du sie lesen kannst.
    ich hatte ja selbst bei meinem späteren "5-Zeilen-Streifen"-Gedanken gemerkt, dass die Bitmap-Daten (bei ausreichend schneller LAN-Hardware) schnell genug wären. Allerdings muss man bedenken, dass (egal ob Bitmaps oder Text) nicht nur lesbarer Text auf dem Screen erscheint, sondern wahrscheinlich auch immer noch eine Menge Lücken/Flächen/Bildelemente, die eben nicht gelesen werden, sondern über die man evtl. schnell weg-scrollen möchte.

    Rapid Eraser schrieb:

    Was man noch erwähnen sollte: Markdown u.ä. eignen sich leider nicht für ein partielles Rendering.
    Warum nicht? Gerade MD sollte sich eher als HTML dafür eignen, weil es bei MD keine schließenden Tags gibt, die evtl. am Anfang des Dokuments geöffnet werden und erst am Ende geschlossen.

    Rapid Eraser schrieb:

    Weiss jemand zufällig wie Contiki das handhabt?
    Contiki muss ja komplexes HTML verarbeiten und wird wahrscheinlich bei einem Seitenwechsel wieder die ganze Seite laden – die Geschwindigkeit lässt das zumindest vermuten. Da Contiki aber OS ist, kann man die Infos bestimmt irgendwo finden – schlimmstenfalls im Quellcode.

    Rapid Eraser schrieb:

    Wie läuft das denn heute? Braucht man immer noch dedizierte Rechner in die man sich mit so geringen Baudraten einwählen kann oder kann man einen 08/15 DSL-Anschluss verwenden? Wo würden dann solche Späße wie der TCP/IP oder DHCP gehandelt?
    Heutzutage hat man üblicherweise einen DSL-Router und der hängt im lokalen (W)LAN – und alle verbundenen Rechner gehen über den ins Internet. Hat man nur einen einzelnen Rechner, hängt der halt alleine (auch per LAN-Kabel oder WLAN) am DSL-Router. Heutzutage läuft, soweit ich weiß, alles interne, wie externe, über TCP/IP (notfalls getunnelt) ab. Ich bin aber wahrlich kein Netzwerk-Auskenner, da gibt es hier im Forum sicherlich bessere Expertise.

    Was der C64 also können muss, damit er im LAN kommunizieren kann, ist TCP/IP. In Contiki ist z.B. ein entsprechender Stack enthalten (den wir sicherlich "entwenden" dürfen) aber es gibt auch C64-LAN-Hardware, die selbsttätig die Kommunikation übernimmt. Ich verstehe das so, dass dann der C64 selbst keinen TCP/IP-Stack benötigen würde. Wie das bei den schon vorhandnen LAN-Hardwares in TC64 und 1541U gelöst ist, müsste uns hier mal jemand erklären. Ich meine, beim Servant64 spricht man das Netzwerk mit OPEN-Befehlen so ähnlich an, wie übliche, serielle IEC-Geräte.

    Man müsste also mal zusammenstellen, welche Hardware-Lösungen es schon gibt und welche Fähigkeiten (Protokolle, Übertragungsgeschwindigkeit) sie besitzen. Das ganze ist natürlich nur relevant, wenn man nicht direkt einen Raspi an den C64-Expansion-Port hängt.

    Rapid Eraser schrieb:

    Sorry, nein, noch lange nicht, dazu ist die Aufgabe noch viel zu schwammig. Lass mal überlegen, wie könnte man anfangen
    Ich bin auch durchaus davon ausgegangen, dass das "Programmieren" anfangs hauptsächlich aus Lesen besteht.

    Rapid Eraser schrieb:

    - die htmlseite "segmentieren" (aber nach welchen Kriterien?)
    - ggf. Menus/Formulare/Bilder erkennen und separat behandeln
    - unerwünschte Segmente herauswerfen (woran erkennt man die?)
    - in den verbleibenden Segmenten nicht benötigtes/gewünschtes Html/CSS (woran erkennt man das?) löschen
    - ggf. die verbleibenden Segmente vereinfachen (z.B. Layout zurechtrücken)
    - das Dokument in ein noch zu definierendes Ausgabeformat, z.B. Markdown, wandeln (wie sieht die Abbildung von HTML auf Markdown aus?)
    Mein Problem besteht momentan darin, dass du mehr willst, als ich ursprünglich wollte. Es besteht meines Erachtens ein riesiger Unterschied, ob man komplexe Strukturen (DIVs etc.) erhalten/rendern will, um das Layout zu erhalten (nach meinem Verständnis dein Ansatz) oder ob man (mein Ansatz in Anlehnung an Lynx oder Links) einfach fast alle Strukturen ignoriert und entsorgt. Wenn du ansatzweise das Layout rüberretten willst (und sei es auch nur die Hintergrundfarbe), dann muss du auch ins CSS hinein (was ich vermeiden wollte).

    Egal, wie man es angeht – der Schlüssel zum Erfolg ist sicherlich, nicht alles neu erfinden zu wollen, sondern vorhandene Tools zu verwenden und die (dank OpenSource) an die eigenen Wünsche anzupassen. Es macht meines Erachtens keinen Sinn, selbst das HTML zu rendern oder zu filtern, sondern man sollte entweder eine Browser-Engine (z.B. Webkit) darauf hin überprüfen, ob man sie als Proxy verwenden kann oder aber die hier schon oft verlinkten Tools (Lynx als Proxy, HTML-2-MD-Konverter ...) zum Filtern/Konvertieren von HTML verwenden.

    Wenn du als Endergebnis des Proxys (egal ob der jetzt auf einem Raspi oder auf einem öffentlich erreichbaren Server läuft) Bilder bekommen möchtest, die in Ansätzen dem Original-Layout entsprechen, dann gibt es meines Erachtens nur die Lösung, dass du mit Webkit (o.ä.) einen Browser (für den Server) programmierst, der ein (virtuelles) Fenster in 320 x 200 Pixeln (für andere Systeme andere Maße) öffnet (darüber wahrscheinlich die mobile Ansicht vom Webserver geliefert bekommt, wenn vorhanden), die Texte mit meinem Pixelfont rendert und das Ergebnis dann als Bild (z.B. PNG ) herausgibt. Das kann man danach in C64-Hires umrechnen.

    Wenn das Konvertieren erstmal als Proxy auf einem lokal aufgesetzten Server funktioniert (also komplexes HTML rein und irgendwas weniger komplexes raus), dann kann man mal gucken, an welchen Positionen man Stellschrauben ansetzen muss.

    Mein Vorschlag wäre also, erst einmal irgendwas Proxy-ähnliches zum Laufen zu kriegen, egal was es tut. Vielleicht mit einem der schon vorhandenen Konverter als Basis. Egal, welche Lösung wir anstreben sollten, müssen ja Daten on-the-fly gefiltert/konvertiert werden. Den Proxy sollte man im lokalen Netz über seine IP-Adresse mit einem normalen Webbrowser aufrufen können und vielleicht in der Browser-Zeile die URL der anzuzeigenden Website übermitteln. ich denke, alles weitere kann man planen, wenn das erstmal läuft. Oder wie siehst du das?
  • Neu

    Hexworx schrieb:

    Von den Bitmapdaten würde ich völlig weg gehen, da es ja auch plattformübergreifend sein/werden soll.
    Obwohl ich ja auch kein Freund der Bitmap-Lösung war, sehe ich das nicht als zu großes Problem. Der Proxy darf dann eben nicht festgelegt werden auf eine Auflösung oder Farbtiefe, sondern muss für jeden Client was eigenes passend rendern. Das sollte möglich sein.

    Hexworx schrieb:

    Markdown ist ja schon schön klein, muss dann aber komplett 'durchgescannt' werden, um HTML (oder eben das 8-Bit-Browserformat) zu erzeugen.
    Wer will denn aus MD wieder HTML machen? Das ist zwar der gängigere Weg, weil MD eigentlich zum einfachen ERSTELLEN von formatiertem Text dient aber hier ist das gar nicht gefordert. MD soll ja das ZIEL-Format sein.

    Hexworx schrieb:

    Es ist ja eben noch absolut NULL 'Code' enthalten (für die Formatierung etc.).
    Jein. Der Code ist klartextlich zu erkennen. Es sind keine klassischen Tags in "spitzen Klammern" enthalten aber # leitet z.B. eine Überschrift ein, ## eine Unter-Überschrift und *text* macht den Text kursiv.

    Hexworx schrieb:

    Gibt es denn (überhaupt) auch einen Konverter HTML -> Markdown? Keine Ahnung. Ich denke nicht. Geht wohl auch gar nicht und bringt ja auch eh nix.
    Wir hatten bestimmt schon 3 bis 5 Lösungen hier gepostet und ausprobiert.
  • Neu

    Wieso eigentlich MD?
    Wäre das auf dem Endgerät soviel einfacher zu verarbeiten als ein klares <i>kursiv</i> oder <h1>überschrift</h1> ?

    Reden wir hier überhaupt nur von einfachen HTML-Tags oder auch von style-Anweisungen im Quelltext a la <div style='font-weight:bold;'>fett</div> oder <p class='vollfett'>fett</p> ?
    carrier lost...
  • Neu

    Retrofan schrieb:

    Obwohl ich ja auch kein Freund der Bitmap-Lösung war, sehe ich das nicht als zu großes Problem. Der Proxy darf dann eben nicht festgelegt werden auf eine Auflösung oder Farbtiefe, sondern muss für jeden Client was eigenes passend rendern. Das sollte möglich sein.
    Auf die Art hat man auf der Zielmaschine aber keinen Einfluss mehr auf z. B. eine bevorzugte Schriftart, was ich schade fände. Und wie soll das bei einer gerenderten Bitmap mit den Button/Menüs funktionieren? Da müsste ja noch zusätzlicher Code übertragen werden und Koordinaten etc.. Bei diesen Dingen müsste die Zielmaschine ja eh noch in die Bitmap eingreifen/schreiben.

    Retrofan schrieb:

    Wer will denn aus MD wieder HTML machen? Das ist zwar der gängigere Weg, weil MD eigentlich zum einfachen ERSTELLEN von formatiertem Text dient aber hier ist das gar nicht gefordert. MD soll ja das ZIEL-Format sein.
    Bei MD gehen aber einige Befehle/Formatierungen verloren (zusammenhängende Absätze, erzwungener Zeilenumbruch, Aufzählungen etc.), die auf der Zielmaschine gebraucht werden könnten bzw. gebraucht würden. Zudem hat MD kein einheitlichen bzw. ja gar kein System bei den Befehlen entgegen HTML mit "<> </>". Gerade diese ankündigenden und beendenden TAGS fände ich wichtig beizubehalten. Zudem müssten ja auch noch die Farben untergebracht werden. Da bin ich wieder bei meinem "@@" als Befehls-Beispiel: @@cFF (Color Vorder-/Hintergrund); @@u: Underline etc.

    Retrofan schrieb:

    Jein. Der Code ist klartextlich zu erkennen. Es sind keine klassischen Tags in "spitzen Klammern" enthalten aber # leitet z.B. eine Überschrift ein, ## eine Unter-Überschrift und *text* macht den Text kursiv.
    Siehe oben ("kein System"). Der Text müsste umständlich nach verschiedensten Merkmalen durchforstet werden.

    Retrofan schrieb:

    Wir hatten bestimmt schon 3 bis 5 Lösungen hier gepostet und ausprobiert.
    Stimmt.

    Immer noch mein Fazit: Übertragung in einer HTML-artigen Textdatei mit TAGS. Dann hat die Zielmaschine auch noch was zu tun und verkommt nicht zum Anzeigegerät. Und es brauchen eben nur 1K (+x) statt 8+1K (+x) übertragen werden.

    @Chagizzz: Dann sehen wir das ja ähnlich. Es kann aber sein, Retrofan meint das mit dem MD irgendwie anders und wir reden aneinander vorbei.
    Read'n'Blast my jump'n'stop-text-sprite-scroller Select A Move

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?
  • Neu

    Chagizzz schrieb:

    Wieso eigentlich MD?
    Wäre das auf dem Endgerät soviel einfacher zu verarbeiten als ein klares <i>kursiv</i> oder <h1>überschrift</h1> ?
    Warum MD, habe ich eigentlich schon mehrfach versucht zu erklären. Kurz: Es ist nicht mal halb so lang – ergo weniger Datenübertragung und weniger Speicherverbrauch. Und es gibt Konverter und es ist ein Standard und es kennen sich viele damit aus. Aber wie auch schon oft gesagt: Es ist nur eine Idee, nur ein Vorschlag, es kann auch gerne HTML, WML oder SGXMLPLUSV8;) sein – Hauptsache kompakt.

    Chagizzz schrieb:

    Reden wir hier überhaupt nur von einfachen HTML-Tags oder auch von style-Anweisungen im Quelltext a la <div style='font-weight:bold;'>fett</div> oder <p class='vollfett'>fett</p> ?
    Was heißt in diesem Zusammenhang "reden"? Ja, das kann (wegen mir) weg, wie externes CSS auch. Bzw., solange eindeutig ist, wie die Auszeichnung aussehen soll (bei selbst vergebenen Klassennamen schwierig), kann man es durch entsprechende Codes (in MD wäre das **fett**) ersetzen.

    Hexworx schrieb:

    Auf die Art hat man auf der Zielmaschine aber keinen Einfluss mehr auf z. B. eine bevorzugte Schriftart, was ich schade fände. Und wie soll das bei einer gerenderten Bitmap mit den Button/Menüs funktionieren? Da müsste ja noch zusätzlicher Code übertragen werden und Koordinaten etc.
    Ja, es müsste natürlich zusätzlicher Code übertragen werden. Die Bitmap-Lösung sollte aber besser Rapid Eraser "verteidigen", ich finde sie interessant aber weniger zielführend als echten Text.

    ZeHa schrieb:

    Uebrigens gibt es noch einen weiteren Nachteil bei Bitmaps: Der C64 weiss gar nicht, was da geschrieben steht. Man kann also z.B. keine Suchfunktion einbauen oder sowas.
    Ja, das ist auch ein Problem von Bitmaps. Ich sehe es aber als noch problematischer an, dass man den Text nicht insgesamt oder in Auszügen kopieren/speichern kann. Vielleicht braucht man das aber alles auch gar nicht auf dem C64 – man sollte es aber im Hinterkopf behalten.

    Hexworx schrieb:

    Bei MD gehen aber einige Befehle/Formatierungen verloren (zusammenhängende Absätze, erzwungener Zeilenumbruch, Aufzählungen etc.), die auf der Zielmaschine gebraucht werden könnten bzw. gebraucht würden.
    Lies dir die Definitionen nochmal (z.B. auf Wikipedia) durch – da geht anscheinend mehr als du denkst. Und was nicht geht, kann man gerne hinzuerfinden, schließlich gibt es auch MD-Erweiterungen (z.B. für Tabellen)

    Hexworx schrieb:

    Zudem hat MD kein einheitlichen bzw. ja gar kein System bei den Befehlen entgegen HTML mit "<> </>".
    Dafür, dass es anscheinend "kein System" gibt, gibt es aber doch (schon vom Erfinder) wunderbare Tools, um HTML in MD und zurück zu wandeln. Ganz so systemlos wird es also nicht sein. Das ist ein Grund, warum ich es ausgewählt hatte – es ist ein Standard, er ist erweiterbar, es gibt dutzende von Tools, man muss das Rad nicht nochmal neu erfinden.

    Hexworx schrieb:

    Zudem müssten ja auch noch die Farben untergebracht werden.
    MD können wir nach Belieben erweitern. Schließlich würden die Browser so programmiert werden, dass sie "unseren" MD-Dialekt verstehen. Wir könnten also Farben im RGB-Farbraum übertragen (und dem Browser die Wandlung auf Systemfarben überlassen) oder mit 16 oder 64 oder 128 Farbnamen oder was auch immer.

    Hexworx schrieb:

    Da bin ich wieder bei meinem "@@" als Befehls-Beispiel: @@cFF (Color Vorder-/Hintergrund); @@u: Underline etc.
    Mir ist das egal – wenn es kurz ist, können wir auch gerne sowas nehmen. Der Nachteil ist halt, dass es keiner kennt, es keine Tools gibt und keinen Standard. Man muss dann halt alles selber machen. Aber ich will dem nicht im Weg stehen – wenn du einen PHP/Ruby-Konverter von HTML zu @@-Code programmierst, dann nehmen wir halt den.

    Wobei meine Ausführungen zu Markdown natürlich nur relevant sind, wenn überhaupt Text – und nicht Grafik – übertragen werden soll. Da der ausführende Programmierer die Richtung vorgibt, sind wir aber erstmal bei Grafik-Output und nicht bei Text mit Tags.
  • Neu

    Retrofan schrieb:

    Warum MD, habe ich eigentlich schon mehrfach versucht zu erklären. Kurz: Es ist nicht mal halb so lang – ergo weniger Datenübertragung und weniger Speicherverbrauch. Und es gibt Konverter und es ist ein Standard und es kennen sich viele damit aus. Aber wie auch schon oft gesagt: Es ist nur eine Idee, nur ein Vorschlag, es kann auch gerne HTML, WML oder SGXMLPLUSV8;) sein – Hauptsache kompakt.
    Auf einzelne Bytes dürfte es dabei nicht ankommen, d.h. <b>fett</b> oder **fett** ist diesbezüglich sicher wurscht. Ein </b> ist allerdings vermutlich auf dem c64 einfacher umsetzbar - klar ** würde eben bei eingeschalteter Fettschrift auf normal umschalten und umgekehrt, also wäre sicher auch nicht schwerer. Allerdings werden Kombinationen wie fett und kursiv (wenn man dafür z.B. ***fett und kursiv*** oder ___fett und kursiv___ verwendet etwas mühsamer.
    Formulare (ja, das wurde auch schon besprochen) müssten ebenfalls irgendwie übermittelt werden und da halte ich die reduzierte Original-HTML Version für sinnvoll.
    Klar, alles was nicht dargestellt werden soll/kann, kann vorher rausgefiltert werden, dann bleibt an HTML ja nicht mehr soviel übrig.
    Und ggf. könnte man auch im Browser einstellen ob man bestimmte Elemente angezeigt oder gefiltert bekommen möchte.

    Retrofan schrieb:

    Ja, das kann (wegen mir) weg, wie externes CSS auch.
    Ich nehme an, dass beruht auf Deine Profi-Wissen. Ich selbst nutze solche Krücken doch häufiger (zugegeben). Aber aufgrund der ohnehin eingeschränkten Darstellung auf dem Endgerät kann man das dann wohl wirklich unterschlagen.

    Hexworx schrieb:

    Auf die Art hat man auf der Zielmaschine aber keinen Einfluss mehr auf z. B. eine bevorzugte Schriftart, was ich schade fände.

    Retrofan schrieb:

    Ich sehe es aber als noch problematischer an, dass man den Text nicht insgesamt oder in Auszügen kopieren/speichern kann. Vielleicht braucht man das aber alles auch gar nicht auf dem C64 – man sollte es aber im Hinterkopf behalten.
    Stimme zu.
    Suche ist bei der geringen Datenmenge meiner Meinung nach eher zu vernachlässigen.

    Also um grundsätzlich mit PHP den Quelltext um TAGS und Script/Style Teile zu reduzieren dürften ja nur wenige Zeilen erforderlich sein.
    Ob das am Ende MD oder reduziertes HTML wird, ist auch relativ wurscht.

    Was muss dann aber noch gemacht werden?

    Splitten großer Seiten in mehrere abrufbare Elemente (vermutlich mit Sessions)
    Formulardaten empfangen und übermitteln (da hab ich mal gerade keinen Plan)
    Bilder umwandeln (hab ich gar keine Ahnung und halte es für sehr aufwendig)
    Links weiterleiten (vielleicht eher direkt vom Endgerät aufgerufen)
    carrier lost...
  • Neu

    Retrofan schrieb:

    Gerade MD sollte sich eher als HTML dafür eignen, weil es bei MD keine schließenden Tags gibt, die evtl. am Anfang des Dokuments geöffnet werden und erst am Ende geschlossen.
    Vielleicht werden sie bei MD nicht End-Tags genannt, aber wenn ich das richtig erkannt habe verwendet z.B. deine Erweiterung für Formulare dieses Konzept. Für Menus werden wir das wohl ebenfalls benötigen. Bei den Steuerzeichen für Hervorhebung ("*" bzw. "_") ist's sogar noch schlimmer, dort kann man nur aufgrund des Kontextes zwischen Start und Ende unterscheiden. Mir sind noch ein paar weitere "potentiell kritische" Stellen bei MD aufgefallen, aber das mag vom jeweiligen Dialekt abhängen. Mal schauen wie wir das in den Griff bekommen. Den Browser für den C64 würde ich aber schon gerne so simpel wie nur möglich halten, sonst findet sich womöglich niemand der den kompletten Standart implementiert.


    Retrofan schrieb:

    Ich meine, beim Servant64 spricht man das Netzwerk mit OPEN-Befehlen so ähnlich an, wie übliche, serielle IEC-Geräte.
    Es wäre natürlich auch ein interessantes Konzept wenn der Server für jede Webseite ein Executable verschicken würde. :D

    Quellcode

    1. LOAD"https://www.forum64.de/index.php?post-add/59905-webbrowser-f%C3%BCr-8-bit-rechner/",13,1
    2. RUN


    Retrofan schrieb:

    Mein Problem besteht momentan darin, dass du mehr willst, als ich ursprünglich wollte.
    Stimmt, so sieht's aus. Wie bereits gesagt, surfen à la Lynx hatten wir ja vor 20 Jahren schon (und ehrlich gesagt hat es schon damals keinen großen Spaß gemacht). Einen grafischen Browser auf dem C64 sehe ich hingegen als noch offenes und relativ interessantes "Forschungsprojekt" an.


    Retrofan schrieb:

    Mein Vorschlag wäre also, erst einmal irgendwas Proxy-ähnliches zum Laufen zu kriegen, egal was es tut. Vielleicht mit einem der schon vorhandenen Konverter als Basis. Egal, welche Lösung wir anstreben sollten, müssen ja Daten on-the-fly gefiltert/konvertiert werden. Den Proxy sollte man im lokalen Netz über seine IP-Adresse mit einem normalen Webbrowser aufrufen können und vielleicht in der Browser-Zeile die URL der anzuzeigenden Website übermitteln. ich denke, alles weitere kann man planen, wenn das erstmal läuft. Oder wie siehst du das?
    Soweit könnte man das zwar leicht mit einem Perlscript erschlagen doch das wäre - naja - Pfuscharbeit (zumindest wenn ich das so zusammenhacken würde...). Eine solide Lösung sähe in meinen Augen anders aus. Doch wir können es ja mal so versuchen*.


    Retrofan schrieb:

    Wir hatten bestimmt schon 3 bis 5 Lösungen hier gepostet und ausprobiert.
    Aber wirklich "nur mal eben ausprobiert", um festzustellen ob "irgendetwas" herauskommt. Ich glaube keiner hier hat versucht seinen täglichen Surfbedarf auf diese Weise zu decken um Vor- und Nachteile der einzelnen Engines zu erkennen, um Unzulänglichkeiten und Verbesserungsmöglichkeiten benennen oder gar eine Empfehlung für eine bestimmte Engine abgeben zu können. Oder auch nur inwiefern die ganze Idee in der Surf-Praxis überhaupt einigermaßen tragfähig ist. Es dürfte ja irgendwo begründet sein, das man seinerzeit bei PDAs, J2ME-Phones etc. nicht einfach auf ein html2markdown- oder html2wap-Skript gesetzt sondern erheblich größeren Aufwand betrieben hat.


    Hexworx schrieb:

    Und wie soll das bei einer gerenderten Bitmap mit den Button/Menüs funktionieren? Da müsste ja noch zusätzlicher Code übertragen werden und Koordinaten etc.. Bei diesen Dingen müsste die Zielmaschine ja eh noch in die Bitmap eingreifen/schreiben.
    Es würde vermutlich genauso funktionieren als hätte der C64 die Darstellung selber gerendert/geprintet. Auch da bräuchte er ja entsprechende Datenstrukturen welche die Position von "anklickbaren Elementen" beinhalten und müsste ggf. ebenfalls in die Darstellung eingreifen. Ob der c64 diese Daten selber bestimmt oder geliefert bekommt ist dabei glaube ich eher zweitrangig.
    Die Übertragung von fertigen Bitmaps war aber auch nur ein Gedanke, einer von vielen. Jedoch, wenn ich das hinzufügen darf: Wir wären wohl produktiver wenn wir uns weniger Gedanken über die Probleme einzelner Ansätze und mehr Gedanken über die Lösungsmöglichkeiten derselben machten. (soll keine Kritik an dir sein; ist halt nur etwas das man allgemein in Forenthreads immer mal wieder in Erinnerung rufen darf... ;) )


    Chagizzz schrieb:

    Also um grundsätzlich mit PHP den Quelltext um TAGS und Script/Style Teile zu reduzieren dürften ja nur wenige Zeilen erforderlich sein.
    Ob das am Ende MD oder reduziertes HTML wird, ist auch relativ wurscht.

    Was muss dann aber noch gemacht werden?

    Splitten großer Seiten in mehrere abrufbare Elemente (vermutlich mit Sessions)
    Formulardaten empfangen und übermitteln (da hab ich mal gerade keinen Plan)
    Bilder umwandeln (hab ich gar keine Ahnung und halte es für sehr aufwendig)
    Links weiterleiten (vielleicht eher direkt vom Endgerät aufgerufen)
    Wenn du in PHP fit bist dann versuch dich doch mal daran. Ich glaube Retrofan würde sich über einen Prototypen schon freuen, und er könnte uns glaube ich helfen klarer zu sehen wie's weitergehen soll.


    * Da meine Kenntnisse in Perl/CGI/Web-Programmierung schon arg eingerostet sind kann das wohl ein paar Wochen dauern...
    Und nicht vergessen: SW-Entwickler hassen es wie die Pest wenn der Kunde im Nachhinein mit Änderungswünschen aller Art ankommt. ;)
  • Benutzer online 1

    1 Besucher