... | ... | @@ -10,6 +10,9 @@ Eine Design-Entscheidung von drasyl war es, dass wir keine Garantien geben, dass |
|
|
|
|
|
Man müsste gucken wie TCP die Reihenfolge der Pakete sicherstellt und das dann in eine Erweiterung gießen.
|
|
|
|
|
|
# Objekt-/Nachrichten-Serialisierung
|
|
|
drasyl verschickt/empfängt nur Byte-Arrays. Jede Applikation muss sich selbst um die (De)serialisierung der Nachrichten kümmern. Hier könnte man den Entwickler an die Hand nehmen und Hilfestellungen leisten. Man könnte Code-Beispiele mit drasyl & [Jackson](https://github.com/FasterXML/jackson) zeigen.
|
|
|
|
|
|
# Streams
|
|
|
drasyl selbst arbeitet nachrichtenbasiert. Man könnte darauf aufbauend eine implementation für Datenströme bereitstellen. Wenn möglich, sollte auf den JDK-Klassen InputStream und OutputStream aufbaut werden.
|
|
|
|
... | ... | |