TFileStream erweitern

[Socke]

Hallo,
da ich gerade die Header-Dateien der libgio übersetze sind mir ein paar Gedanken gekommen. Für alle, die nicht wissen was das ist: libgio ist eine Bibliothek als Teil der GLib (GTK+), die einfachen Zugriff auf Dateien mittels diverser Protokolle ermöglicht (file, ftp, http, usw.) ohne jedes Mal eine andere API zu verwenden.

Dort gibt es auch verschiedene Stream-Klassen; nicht wirklich verwunderlich, aber mir ist die Idee gekommen, dass man diese auch in den bestehenden FPC-Klassen kapseln könnte.

Dabei wäre eine neue TGioStream (o.a) von TStream abgeleitet möglich, die dann in diversen x.LoadFromStream() Methoden verwendung finden könnte.

Die Zweite Idee ist ein bisschen radikaler und sieht vor TFileStream komplett zu hacken. Demnach wäre TFileStream nur noch ein Frontend für Dateistreams, welches auf ein ein Backend, das den letztendlichen Zugriff implementiert, zurück greift. Damit wäre es möglich das Backend frei zu wählen, sodass standardmäßig in der unit Classes ein RTL-basiertes Backend verwendet wird, welches (ähnlich des Memory-Managers) aber ausgetauscht werden kann. Bspw. könnte eine zweite Unit in ihrem initialization-Abschnitt entsprechende Variablen mit einem eigenen Backend verlinken, sodass ab jetzt immer auf dieses zugegriffen wird (ich stelle mir das ähnlich der LCL vor, aber evtl. zur Laufzeit austauschbar).
Der Vorteil wäre, dass alle Programme, die diese Unit (und damit die libgio) verwenden automatisch (ohne weiteren Aufwand) entsprechende Funktionen verwenden könnten. Das ganze wäre dann auch für alle Plattformen, die von der Bibliothek unterstützt werden (LInux, Max und Windows) verfügbar.

Jetzt ist eure Meinug dazu gefragt.

[theo]

Das erste find ich gut "TGioStream (o.a) von TStream abgeleitet ", dafür ist die abstrakte TStream Klasse da.
Die zweite Idee könnte zum Horror werden.

P.S. Wenn man nicht angemeldet ist, kommen manchmal lustige Sachen.
Siehe angehängtes Bild, wenn man über "Socke" hovert.

[Socke]

Das erste find ich gut "TGioStream (o.a) von TStream abgeleitet ", dafür ist die abstrakte TStream Klasse da.
Die zweite Idee könnte zum Horror werden.

P.S. Wenn man nicht angemeldet ist, kommen manchmal lustige Sachen.
Siehe angehängtes Bild, wenn man über "Socke" hovert.

Das mit dem Horror bei Nummer Zwei stelle ich mir so ähnlich wie bei der LCL vor... keine Dokumentation und niemand weiß wie's funktioniert Aber wahrscheinlich ist so ein PlugIn-System viel zu unnötig (mit Tauben auf Spatzen geschossen oder wie war das?). Mir fällt nämlich gerade sonst nichts ein, was man sonst noch so da verwenden könnte (vor allem, da die libgio schon fast alles kann und selbst erweiterbar ist).

[monta]

Also ich wäre ja auch für ersteres. Erscheint mir zum einen die sauberere Lösung zum anderen glaub ich, das es schwer wird, jemanden bei der zwieten Lösung davon zu überzeugen, das fest in Lazarus zu integrieren.

[Socke]

Also ich wäre ja auch für ersteres. Erscheint mir zum einen die sauberere Lösung zum anderen glaub ich, das es schwer wird, jemanden bei der zwieten Lösung davon zu überzeugen, das fest in Lazarus zu integrieren.

Mittlerweile bin ich auch dafür, dass ich erstere Variante bevorzuge; da muss ich nicht direkt alles hacken (ich hab so schon wenig Ahnung von den internen Innereien der vorhandenen Streams).

Mit ein paar C-Konstrukten, bin ich mir nicht sicher, ob ich das richtig übersetzt habe:
const char *choices[]: Ich weiß nur, dass das anscheinend ein Array auf PChar sein soll; Der Compiler meint aber, dass Arrays in C-Prozeduren als Referenz übergeben werden. Was wäre also richtig:

Code: Alles auswählen

// void (* ask_question) (GMountOperation *op, const char *message, const char *choices[]);
  ask_question: procedure (op: PGMountOperation; message: PChar; choices: array of Pchar); cdecl;
// oder
  TArrayPChar = array of PChar;
  PArrayPChar = ^TArrayPChar
  ask_question: procedure (op: PGMountOperation; message: PChar; choices: PArrayPChar); cdecl;

Dann habe ich noch folgende Konstrukt:

Code: Alles auswählen

const void*  g_buffered_input_stream_peek_buffer (GBufferedInputStream *stream, gsize *count);

Ist das eine eine Funktion, die einfach nur einen Zeiger zurück liefert oder heißt das const void* irgendetwas anderes?

Edit: Da ich jetzt fast alle Header übersetzt habe, gehts langsam an die Implementation der Pascal-Klasse. Wäre eine Klasse, die sich genau so wie TFileStream verhält oder eine solche, die möglichst viel von den zusätzlichen Möglichkeiten bietet, besser geeignet.
Erstere Variante wäre in der Umstellung einfacher; aber die Auffassung der Datei-Modes von Pascal ist im Vergleich zur libgio ein bisschen seltsam, weshalb es etwas mehr Aufwand wäre (ein paar mehr Abfragen und bedingt andere API-Calls).

[theo]

Das erste ist wahrsch. ein PPChar (Zeiger auf das erste Element eines PChar "Array").
Das zweite gibt einen unspez. Pointer zurück.

[theo]

Eine Frage habe ich noch: Wenn du dir schon diese Mühe machst, warum dann nicht gleich mit den Pascal Crossplatform Libraries?
Gegen eine Klasse TURIStream ist nichts einzuwenden, aber warum nicht einfach mittels LNet oder Synapse?

[Socke]

Das erste ist wahrsch. ein PPChar (Zeiger auf das erste Element eines PChar "Array").
Das zweite gibt einen unspez. Pointer zurück.

Danke, eingebaut.

Eine Frage habe ich noch: Wenn du dir schon diese Mühe machst, warum dann nicht gleich mit den Pascal Crossplatform Libraries?
Gegen eine Klasse TURIStream ist nichts einzuwenden, aber warum nicht einfach mittels LNet oder Synapse?

Pragmatisch: Weil ich die ganzen Header-Dateien bereits übersetzt habe und ich mich dann auch erst in LNet oder Synapse einarbeiten müsse.

Andererseits gibts mit der libgio bereits das, was ich brauche. Ich muss also nicht alles selbst implementieren sondern nur die richtigen API-Calls benutzen, was vor allem bei asynchronen Vorgängen einfacher sein dürfte.

Für andere Leute heißt das vor allem: eine externe Bibliothek, die mit verteilt werden muss. Unter Linux sollte das kein großer Aufwand (dank Paketmanagement) sein, und selbst unter Windows dürfte der Aufwand eher gering ausfallen. Problematisch dürfte es dann aber für alle sein, die unter nicht x86/x86_64 Architekturen oder anderen Betriebssystemen als Windows/Linx/Mac/Unix arbeiten. Ich weiß aber auch nicht, wie dort der Bedarf von vergleichbaren Lösungen ist.

[theo]

Andererseits gibts mit der libgio bereits das, was ich brauche.

Was brauchst du denn?

Ich meine, es gibt auch z.B. bei Synapse sehr einfache Kommandos wie:
http://synapse.ararat.cz/doc/help/https ... ttpGetText" onclick="window.open(this.href);return false;
http://synapse.ararat.cz/doc/help/ftpse ... FtpGetFile" onclick="window.open(this.href);return false;

Welche Funktionalität benötigst du denn?

[Socke]

Andererseits gibts mit der libgio bereits das, was ich brauche.

Was brauchst du denn?

Ich meine, es gibt auch z.B. bei Synapse sehr einfache Kommandos wie:
http://synapse.ararat.cz/doc/help/https ... ttpGetText" onclick="window.open(this.href);return false;
http://synapse.ararat.cz/doc/help/ftpse ... FtpGetFile" onclick="window.open(this.href);return false;

Welche Funktionalität benötigst du denn?

Mein Programm soll lokale und entfernte ((S)FTP) Verzeichnisse synchronisieren. So wie ich das sehe, hat auch Synapse recht einfach zu benutzende Funktionen um die Dateien hin und her zu schieben und Datei-/Verzeichnisinformationen zu erhalten. Den wesentlichsten Nachteil bei Synapse sehe ich darin, dass keine asynchronen Methoden vorhanden sind (oder ich hab sie einfach übersehen). Da ich ein grafisches Programm schreibe, müsste ich also noch einen extra Thread für die Dateiübertragung schreiben.

[theo]

Den wesentlichsten Nachteil bei Synapse sehe ich darin, dass keine asynchronen Methoden vorhanden sind (oder ich hab sie einfach übersehen). Da ich ein grafisches Programm schreibe, müsste ich also noch einen extra Thread für die Dateiübertragung schreiben.

Im Grunde ja, es gibt aber das Heartbeat Feature, welches man mal testen könnte.
http://synapse.ararat.cz/doku.php/publi ... :heartbeat" onclick="window.open(this.href);return false;

[Socke]

Den wesentlichsten Nachteil bei Synapse sehe ich darin, dass keine asynchronen Methoden vorhanden sind (oder ich hab sie einfach übersehen). Da ich ein grafisches Programm schreibe, müsste ich also noch einen extra Thread für die Dateiübertragung schreiben.

Im Grunde ja, es gibt aber das Heartbeat Feature, welches man mal testen könnte.
http://synapse.ararat.cz/doku.php/publi ... :heartbeat" onclick="window.open(this.href);return false;

Ich werd's mir mal ansehen. Ich werde aber erstmal versuchen meinen TGIOStream fertig und funktionsfähig zu bekommen.
Die libgio hat aber immer noch einen Vorteil: Ich kann sowohl für lokale als auch für entfernte Dateien das selbe Interface benutzen (Auch wenn ich dann direkt die API verwenden werde)