An dieser Stelle sind einige Dinge zusammengefaßt, die die Zukunft der Roblet®-Technik - in technischer Hinsicht - betreffen.
Nutzerkonzept und Verschlüsselung
Ein Nutzerkonzept ist in Vorbereitung. Die Kommunikation zwischen Anwendung und Server wird dann verschlüsselt und authentisiert verlaufen. Das Nutzerkonzept wird mit öffentlichen und privaten Schlüsseln arbeiten. Der existierende Prototyp ist an das erfolgreiche SSH angelehnt und ermöglicht, daß Anwendungen und Server bis auf absolut notwendiges Minimum ohne Paßworteingabe auskommen.
Im Zusammenhang mit dem Nutzerkonzept stehen dann auch neue Funktionen des Roblet®-Servers. Roblet®-Anwendungen werden in der Lage sein, auch Roblets® zu betreuen, die nicht direkt von ihnen kommen, sondern vielmehr ihrem Nutzer angehören. Das schließt die Schaffung eines Generalnutzers (superuser) ein, der alle Roblets® betreuen kann.
Listener-Konzept für Verbindungszustand
Die Klienten-Bibliothek versucht generell alles, um eine Verbindung zu einem gewünschten Server aufzubauen, aufrechtzuerhalten oder wiederherzustellen. Das bedeutet für alle Anwendungen eine grundlegende Erleichterung, da derartige Konzepte nur mit sehr viel Aufwand selbst zuverlässig implementiert werden können. Demgegenüber müssen jedoch Anwendungen, welche mit dem Menschen in direktem Kontakt stehen, diesen darüber aufklären, was im Falle von Verzögerungen gerade geschieht bzw. was die Probleme sind.
Die Klienten-Bibliothek wird ein Konzept auf Basis von Listenern (Zuhörer-Instanzen) bereitstellen, welches ermöglicht eine Anwendung synchron darüber zu informieren, was gerade mit einer Netzwerkverbindung geschieht. Diese Informationen können dann beliebig weiterverarbeitet und u.a. auch in Benutzerschnittstellen zur Anzeige verwendet werden.
Roblet® sendet Roblet®
In einigen Projekten schon eingesetzt, jedoch noch nicht dokumentiert, ist die Möglichkeit, daß auch Roblets® selbst Roblets® verschicken können. Jedem Roblet® wird dazu vom jeweiligen Roblet®-Server eine Einheit mit Fähigkeiten à la Klienten-Bibliothek zur Verfügung gestellt. Auf diese Weise entstehen überraschend schnell komplexeste Anwendungen, die jedoch ebenso überraschend einfach handhabbar sind. Das erwartete Chaos wird leicht durch die Einfachheit der Handhabung verhindert. Darüber hinaus erreichten derartige Anwendungen eine erstaunlich gute Les- und Wartbarkeit.
Speicherung von Roblets® und automatisches Laden nach Server-Neustart
Roblets® kommen als Datenstrom beim Server an. Diese Eigenschaft soll genutzt werden, um Roblets® auch persistieren zu können. Damit ist dann auch die Grundlage gegeben, Roblets® z.B. automatisch nach dem Neustart eines Servers (wieder) zu laden.
Soft-Module
Roblets® sollen zukünftig in der Lage sein, dem Roblet®-Server Module übergeben zu können, die der dann bei sich mit einordnet. Dadurch kann die Funktionalität des Roblet®-Server dynamisch zur Laufzeit erweitert werden. Nachfolgende Roblets® können nachfolgend die durch diese Module bereitgestellten Einheiten nutzen.
Auf diese Weise kann prinzipiell die Logik in den "echten" Modulen klein gehalten und damit erfahrungsgemäß die Stabilität der Server deutlich erhöht werden. Die Soft-Module bringen in diesem Fall die noch fehlende Logikvergrößerung. Anders als echte Module können Soft-Module jedoch leicht zur Laufzeit ausgetauscht werden, was nicht nur während der Entwicklungsphase Vorteile bringt.
Beliebige Verzeichnis-Arten
Die momentane Implementierung der Verzeichnis-Anwendung und der Klienten-Bibliothek setzen Jini™ ein. Zukünftig sollen beliebige Arten von Verzeichnissen genutzt werden können.
NAT-PMP und UPnP
Der Server soll per NAT-PMP, UPnP und andere Standards in die Lage versetzt werden, - wenn gewünscht und erlaubt - einen Zugang von außen durch Router mit NAT zu ermöglichen. Damit kann z.B. im Heimbereich die Arbeit aus dem offenen Internet heraus beschleunigt und damit zuverlässiger werden.
Generics für die zentralen Schnittstellen
Die Schnittstellen org.roblet.Roblet und org.roblet.Robot sind momentan hinsichtlich ihrer Rückgabetypen so allgemein gehalten, daß man alles damit machen kann. Allerdings ist in der vorliegenden Fassung der Programmierer gefordert, die richtigen Typenumwandlungen (casts) zu machen.
Zukünftig soll durch den Einsatz der ab Java™ 1.5 verfügbaren Generics das explizite Wandeln der Typen unnötig werden. Damit soll eine noch weitergehende Hilfe durch den Compiler möglich werden.
Einheitenloser Ressourcen-Zugriff
In der vorliegenden Implementierung des Servers werden Ressourcen mit Hilfe von Einheiten bereitgestellt. Ein Roblet kann für den Zugriff auf Ressourcen nicht direkt bestimmte Klassen instanziieren oder nutzen.
Zukünftig sollen Module in der Lage sein, jedem Roblet über einen Klassenlader-Mechanismus auch direkt Klassen zur Verfügung stellen zu können, die in sich dann schon die notwendigen Umsetzungen machen. Dadurch würde dann die Nutzung des org.roblet.Robot entfallen können, was eine weitere Vereinfachung der Technik bedeutet.
Die Tragweite einer solchen Möglichkeit ist nicht zu unterschätzen. Prototypen von Modulen, welche sehr komplexe Datenstrukturen und Funktionen bereitstellen müssen, zeigen, daß das Einheitenkonzept hier an eine natürliche Grenze zu stoßen scheint.
