IO.pbi (IO - Interface) V # 0.3 (+ CHM Help File)

[cxAlex]

Servus.

IO.pbi bietet ein abstraktes Interface für verschiedene IO - Schnittstellen (am häufigsten: File). Dabei gibts es einige Methoden die jede Implementierung enthalten muss und optionale Methoden.

Bereits implementiert sind:

• File
• Memory
• Network
• SerialPort

In Arbeit:

In Planung:

• Gadget
• Process
• Console
• Syncronizer

Die obligatorisch zu Implementierenden Methoden sind:

Code: Alles auswählen

IO\Write(*Mem, MemSize)
IO\Read(*Mem, MemSize)
IO\IsAvailable()
IO\Close()

Write() und Read() sollten klar sein, IsAvailable() gibt an ob und wie viele Daten (ab der aktuellen Position) an der IO - Schnittstelle verfügbar sind und Close() schließt die Schnittstelle/gibt das IO - Objekt frei.

Dann gibt es noch optionale Schnittstellen die (aufgrund Beschaffenheit der konkreten IO - Schnittstelle) nicht immer implementiert sein müssen:

Code: Alles auswählen

IO\GetLenght()
IO\GetPosition()
IO\SetPosition(Position.i)
IO\ImportFromIO(*IO.IO)
IO\ExportToIO(*IO.IO)

GetLenght() gibt die gesamte Länge der Daten der IO Schnittstelle an (Größe einer Datei, Größe eines Memory - Speichers), Get/SetPosition() ändert die Position des Daten-Zeigers innerhalb der IO - Schnittstelle (FileSeek). ExportToIO() exportiert den gesamten Inhalt der IO Schnittstelle an eine andere IO - Schnittstelle, ImportFromIO() importiert von einer IO Schnittstelle.

Damit man festellen kann welche optionalen Methoden ein Objekt unterstützt gibt es noch Verwaltungsfunktionen. Diese sind global, müssen nicht selbst implementiert werden:

Code: Alles auswählen

IO\IOName$()
IO\IOOptionalFunctions()

IOName$() gibt den Namen der Schnittstelle zurück ("FILE","MEMORY",...), IOOptionalFunctions() die optionalen Funktionen (kann mit dem & - Operator geprüft werden, etwa IO\IOOptionalFunctions() & #IO_GetPosition).

ein kleines Verwendungsbeispiel:

Code: Alles auswählen

IncludeFile "IO.pbi"
Define *File.IO, *Memory.IO

*File = IO_File("C:\myFile.data", #PB_File_Read)
*Memory = IO_Memory()
*Memory\ImportFromIO(*File)
*File\Close()

Würde den gesamten Inhalt der Datei in den Memory - IO laden. Danach kann man mit SetPosition/Read/Write genau so arbeiten als wäre man wirklich in der Datei, nur spart man sich die permanenten HDD/SSD - Zugriffe. Natürlich funktioniert das ganze auch umgekehrt, man erzeugt zuerst nur ein Memory - Element, schreibt alle Daten die man benötig hinein und Exportiert das ganze danach einfach in ein File - Element.

Das ganze wird natürlich erst wirklich praktisch sobald die Network und SerialPort - Implementationen dabei sind. Dann kan man z.B. bei einem Network - Event z.b. einfach *Connection\ExportToIO(*Memory) ausführen und das Memory - Objekt so behandeln als hätte man nicht gerade Daten übers Netzwerk empfangen sondern aus einer Datei gelesen.

Die geplante Syncronizer - IO - Schnittstelle wird eine virtuelle IO - Schnittstelle bei der man ein Main - IO - Object definieren kann und beliebig viele Sub - Object. Schreib - Operationen werden auf allen IOs durchgeführt, Lese - Operationen nur am Main - Object. Dadurch kann man z.b. ein Network - IO Object als Main definieren und ein oder mehrer File - Objects als SUB und erhält eine automatische Protokollierung.

IO.pbi:
Download

CHM - Hilfe:
Download

[ts-soft]

interessante Sache,
ist auch ein Stream-Object geplant? Für Dinge die nicht in den Speicher passen.

[cxAlex]

Wohin Streamen? Damit verbinde ich jetzt irgendwie immer Netzwerk?

Gruß, Alex

[ts-soft]

In den Speicher streamen, wenn die Datei zu gross ist um sie auf einmal in den Speicher zu laden.
z.B. zur Anzeige einer riesigen Textdatei oder zum packen/verschlüsseln riesiger Dateien.

[cxAlex]

Ah, schon klar wie das gemeint ist
Ja, ich hab mir schon sowas ähnliches gedacht, sollte nicht so schwer sein. Da wird dann eben in der Export() - Funktion nicht alles in einem SpeicherBlock gepackt und die Write() Funktion des 2. IO - Objekts aufgerufen sondern in Blöcke zerstückelt und die Write() Funktion öfter aufgerufen.

Gruß, Alex

[cxAlex]

Update

Network - IO eingebaut.
Die IO - Proceduren kümmern sich intern um Netzwerk - Empfangsschleifen usw ... .
Da bereits im IsAvailable() empfangen wird und die Read() Funktion nur noch auf einem internen Buffer arbeitet ist für den Programmierer die Größe der Empfangenen Daten bereits VOR dem Aufruf von Read bekannt was an einigen Stellen den Komfort beim Programmieren erhöhen sollte.

Kleines Beispiel, direkter Download in eine Datei:

Code: Alles auswählen

XIncludeFile "IO.pbi"

InitNetwork()

Define Request$ = "GET HTTP/1.1" + #LF$ +
                   "Host: www.purebasic.com" + #LF$

; Open Connection
Define *net.io = IO_Network_Connection("www.purebasic.com", 80)
; Create File
Define *file.io = IO_File(GetTemporaryDirectory() + "download.txt")

; Send Request
*net\Write(@Request$, Len(Request$)*SizeOf(Character))

; Wait for Data
Repeat
  Delay(1)
Until *net\IsAvailable()

; export to file
*net\ExportToIO(*file)

; schließen
*net\Close()
*file\Close()

[NicTheQuick]

Lustigerweise bastel ich gerade selbst an einem BufferedStream. Es ist allerdings etwas anders als das, was du machst, denn bei mir kommen noch Threads dazu. Später kann man dann auch verschiedene Sachen damit verbinden, ähnlich wie bei dir. Ich muss hier halt noch mit Mutexen und Semaphoren arbeiten, damit es auch mit mehreren Threads parallel läuft. Bei mir könnten auch mehrere Threads Daten in den Stream schreiben und nur ein Thread holt sie wieder ab.

[cxAlex]

Lustig, den genau sowas habe ich auch vor mit meinem IO.pbi
Natürlich mal für die 2. Version von meinem EasyNetworkManager, und auch allgemein, also genau was du sagst, Mehrere Threads schreiben auf ein Objekt und das ganze wird danach geordnet nacheinander geschrieben (Input-Queue). Auch will ich eine optinale "Bandbereiten-Begrenzung" einbauen, was man dann ja nicht nur im Netzwerk anwenden kann, z.B. auch die maximale Schreibgeschwindigkeit in eine Datei, natürlich auch Multithread. Ich werde hierbei wohl einen WFQ - Algo anwenden, sollte für Nicht - Netzwerkzwecke besser funktioniern als z.B. WRED.

Das ganze soll dann etwa über einen IO_Thread() funktionieren, der ein beliebiges anderes IO - Object hält und die Zugriffe der Threads darauf wie beschrieben managed. Aber erst implementiere ich mal alle Basis - IO Objekte.

Gruß, Alex

[ts-soft]

Beim Test Deines Beispiels im Unicode-Mode bleibt die Textdatei leer, ich denke mal, da fehlt noch was.

Ausserdem wäre es nett, wenn Du die Dateien Versionieren (mit History) würdest, das macht die Sache
etwas übersichtlicher.

Noch ein Vorschlag zu EnableExplicit:

Code: Alles auswählen

CompilerIf #PB_Compiler_IsMainFile
EnableExplicit
CompilerEndIf

Ich würde es so einfügen, dann haste es aktiv, wenn Du testest, läßt dem Anwender aber die freie Wahl.

Gruß
Thomas

[cxAlex]

Beim Test Deines Beispiels im Unicode-Mode bleibt die Textdatei leer, ich denke mal, da fehlt noch was.

Sehe ich mir gleich mal an.
//Edit: Lag nur am Beispielcode, Len()*SizeOf(Character), so ist's korrekt

Ausserdem wäre es nett, wenn Du die Dateien Versionieren (mit History) würdest, das macht die Sache
etwas übersichtlicher.

Ist schon geschehen

Noch ein Vorschlag zu EnableExplicit:

Code: Alles auswählen

CompilerIf #PB_Compiler_IsMainFile
EnableExplicit
CompilerEndIf

Ich würde es so einfügen, dann haste es aktiv, wenn Du testest, läßt dem Anwender aber die freie Wahl.

Jup. Normal kommentiere ich in Includes die EnableExplizit aus nachdem ich fertig bin, btw. aktiviere sie wenn ich etwas ändere/teste. Da das ganze hier in einem sehr frühen Stadium ist ist das bisher noch nicht geschehen. Der Compiler-Switch ist aber gut, so ähnlich werd ich das realisieren.

Gruß, Alex