JUIBrowser - was haltet ihr davon?

[Linuxhippy]

Hallo,

Ich arbeite gerade an einem Framework ( http://juibrowser.sourceforge.net ) welches es erlaubt am Server swing-ähnlichen code zu schreiben, welcher am Client dann zu einer Swing-UI zusammengebastelt wird.

Ein kleines Stück Beispielcode:

public class UTestApp extends USecureNetworkApplication {
    public void init(UApplet applet){
        super.init();

        UFrame frame = new UFrame();
        frame.setSize(300, 300);
        frame.setVisible(true);
        frame.setLayout(new UBorderLayout());
        frame.add(new UButton("Hello World"), BorderLayout.CENTER);
    }
}

Ich glaub die Idee hätte Potential, weil:
- Client ist sehr klein (30-50kb), größe Unabhängig von der Applikationsgröße, weniger Datenvolumen als XML/HTML
- Kaum Belastung am Server (verglichen mit den großen, aufwändigen String-Operationen für XML oder HTML generierung)
- Gesamte Logik kann am Server "bleiben", keine State-Synchronisation zwischen Client/Server notwendig
- Verschlüsselung "by default" ohne komplizierte SSL-Zertifikate, komprimiertes Protkoll
- Man mit einer angepassten Version von Netbeans' Oberflächen-Builder die Swing-Oberfläche einfach zusammenklicken kann.
- Die Entwicklung analog mit der von normalen Desktop/Swing Anwendungen verläuft - wer Swing kann kann JUIBrowser's API auch - ohne Corba, Servlets, IO/NIO lernen zu müssen.

Das ganze ist noch in einem sehr frühen Stadium, d.h. viele Swing-Komponenten sind noch nicht verfügbar - aber das Framework ist größtenteils feature-complete.
Die Sourceforge-Seite des Frameworks ist: http://juibrowser.sourceforge.net/
Dort gibts auch ein Demo, wobei das ziemlich mieß ist - ein bessers (einer 50kSloc anwendung) ist in Arbeit.

Was haltet ihr von der Idee, was denkt ihr sollte man besser machen - und würde euch daran stören dass ihr es nicht einsetzen würdet?

Mfg Clemens

 

[tuxedo]

Hmm, mir würde jetzt nur ein Verwendungszweck einfallen: Eine Art Terminal-System...

Für "normale" Anwendungen hab ich noch keinen Bedarf gesehen alles auf den Server auszulagern. Und mit RMI unc Co, hatte ich in sofern noch keine Probleme, zumal ich die Logik ja schon im Server abgebildet habe.

Wo würdest du denn den JuiBrowser einsetzen?

- Alex

 

[Linuxhippy]

Wo würdest du denn den JuiBrowser einsetzen?

Ich hätte mir folgende Einsatzszenarien vorgestellt:

- Internetanwendungen mit viel Funktionialität / Code: Egal wie groß die Anwendung am Server ist, der Benutzer lädt das 30-50kb große Applet + ein paar KB für die Anweisungen. Dies wäre eigentlich meine Hauptanwendungsidee

- RMI ist (unoptimiert) vergleichweise langsam aufgrund der vielen Roundtrips, optimiert man die Abfragen handlet man sich auch schon wieder logik am Client ein.

- Firmenanwendungen: Für Windows/Linux-Clients wird es einen nativen Client geben, welche auch ohne Java-Runtime funktioniert. Somit wäre es möglich in großen Firmen zu deployed, ohne dass Java dort instalilert sein muss - und ohne dass man sich einen nativen Compiler wie Excelsior Jet kaufen muss.

Es gibt schon eine derartige Lösung namens ULC, ist aber schweineteuer und hald proprietär - der Grund warum ich mein Projekt gestartet hab ist, dass mein letztes Projekt um einiges einfacher und problemloser realisierbar gewesen wäre ... hätt ich mein Framework damals schon gehabt

lg Clemens

 

[tuxedo]

Im Zeitalter von schnellen DSL-Anschlüssen kann ich mir nocht vorstellen, dass es ein Argument ist, dass der User nut 30..50kbyte runterladen muss. Zumindest nicht für den Client. Serverseitig: Ja, Traffic kostet. Aber mit nem gescheiten Server hat man schnell 1TB und mehr Traffic frei.

RMI: Naja, RMI verfolgt ja nicht das gleiche Prinzip. Serverseitig generierte GUIs haben ja in erster Linie nix mit RMI zu tun, oder?

Firmenanwendungen: Ja, da könnte ich es mir vorstellen. Aber auch hier: Warum die komplette Logik auf den Server auslagern? Die Geschäftslogik ja... aber die GUI-Logik ist doch beim Client eher nicht das Problem, oder?

Läuft in meinem Augen nach wie vor auf ein Thin-Client Prinzip heraus. Und das würde, je nach Anzahl der Clients und Komplexität der Logik, einen sehr starken Server voraussetzen.

- Alex

 

[hupfdule]

Ich sehe es im Grunde genau wie Alex. Das ganze macht für mich Sinn in Fällen, wo extrem schwachbrüstige Clients eingesetzt werden müssen. Aber das erkauft man sich halt mit deutlich erhöhter Serverlast. Da heutzutage nahezu jeder Arbeitsplatzrechner viel zu groß für seine Aufgaben ist, wird es jedoch wohl eher selten vorkommen, dass man ein Einsatzszenario findet, in dem man bereit ist dem Server derartig viel Last zuzumuten.

 

[tuxedo]

Sinn macht es vielleicht auch dort, wo ein Client-Server Tool zum Einsatz kommt, welches immer mal wieder neue Eingabemasken dem Client präsentiert. Dann müsste man den Client nicht updaten und der Teilname "Browser" würde seinem Namen gerecht: Der Server versorgt den Client mit einer servergenerierten Oberfläche.

Man könnte das ganze auch für ein eigenes, krasses Intranet benutzen. Quasi analog zu einem Webserver mit Webbrowser. Allerdings stellt sich da die Frage: Wer macht sowas?

Denke die Zielgruppe für diese API ist ziemlich speziell.
Ich will die API aber um Himmels willen nicht schlecht machen. Nein. Ich find das Teil sogar ziemlich cool. Nur seh ich halt kaum einen Verwendungszweck dafür.

- Alex

 

[hupfdule]

Sinn macht es vielleicht auch dort, wo ein Client-Server Tool zum Einsatz kommt, welches immer mal wieder neue Eingabemasken dem Client präsentiert. Dann müsste man den Client nicht updaten

Würde aber auch super mit Webstart funktionieren. Ich sehe hier keinen Vorteil in o.g. Framework.

 

[tuxedo]

Für Webstart müsste man die Anwendung halt neu starten. So würde das "on the fly" gehen.

- Alex

 

[Linuxhippy]

in dem man bereit ist dem Server derartig viel Last zuzumuten.

Die Serverlast welche durch das Framework erzeugt wird ist minimalst - vieleicht ein zehntel von JSP nicht zu sprechen von JSF. Natürlich, der User-Code an sich (geschrieben vom Bibliotheks-Verwender) belastet den Server zusätzlich.

Würde aber auch super mit Webstart funktionieren. Ich sehe hier keinen Vorteil in o.g. Framework.

Im Grunde ists aufgebaut wie SAP, nur direkter an Java gekoppelt. Mit Webstart würde es funktionieren (ich hab sowas vor einem jahr implementiert) ... super aber nicht
Btw. ich hab schon mal eine "am deckel" bekommen, weil mein Applet 1mb groß war.

Hmm, ja ich denke ihr habt recht. Ich hätte JUIBrowser speziell dort im Einsatz gesehen, wo derzeit AJAX-Anwendungen deployed werden - aber gerade dort wird client-seitiges Java sehr kritisch gesehen und ansonsten ...
Naja mal sehen, ich werd mal mein letztes Projekt neu schreiben damit ... bin schon gespannt über die Erfahrungen.

lg Clemens

 

[tuxedo]

Als ThinClient oder im "Terminal-Bereich" (Dinge wie SAP, BaaN und Konsorten) ist das sicher ne feine Sache. Aber wie gesagt: Das ist ein recht spezielles Gebiet. Für die "alltägliche" Client-Server-Anwendung ist es wohl ein wenig unnötig.

- Alex

 

[Beni]

Ich finde die Idee und Umsetzung cool :toll: Aber wo man den JUIBrowser einsetzen kann, weiss ich leider auch nicht :wink: