Notes Java Applets lokal / Caching möglich ?

[Glombi]

Hi,
einer meiner Kunden fragt nach, ob es möglich sei, die Standard Notes Java Applets für View, Outline, Action Bar, RTF Feld lokal auf den PCs - auf denen bereits Notes installiert ist - aufzurufen oder zu speichern.

Problem: Die User (nutzen Browser) habe teilweise keine performante Anbindung (bspw. Handy) und müssen ewig warten, bis sich im Mail oder Teamroom mal was tut, da dort ständig Applets geladen werden.

Ist es möglich, dass man - durch "Verbiegen" von irgendwelchen Systemvariablen (CLASSPATH oder was weiß ich) den Browser dazu bewegt, die lokalen .class Dateien zu verwenden, anstatt jedesmal die Applets vom Server zu holen.

Andreas

[Semeaphoros]

Hm, weiss nicht so genau, aber ich denke, da ist eh was verbogen. Normalerweise sollte der Brauser doch die Applets cachen? Da ist wohl der Cache entweder irgendwie deaktiviert oder zu klein. Er soll doch mal versuchen, den Wert für die temporären Internet-Dateien höher anzusetzen.

[animate]

ich bin kein erfahrener Web-Entwickler. Aber theoretisch müsste das gehen.
Dazu musst du keine Systemvariablen anfassen. Du musst die Archive/Klassen auf allen Clients haben. Dann musst du bei allen Applets die Angabe, wo sie liegen, ändern.
Ich hab leider grad kein Notes hier, aber morgen kann ich mal schauen, ob und wo man das machen kann.

Der Domino Server muss letztendlich eine HTML-Seite ausspucken, in der halt nicht src="/applet.jar" steht, sondern scr="c:\applet.jar"

Wie gesagt, graue Theorie bis jetzt. Und ob es sinnvoll ist, die Standardschablonen so gravierend zu ändern, kann ich von meiner Warte nicht beurteilen. Außerdem wäre ja dann die Idee der Webmail, für die man eben nix außer nem Browser benötigt, falsch verstanden worden

[Axel Janssen temp]

Normalerweise sollten die Applets nach dem 1. Laden im cache des Browsers sein.
Vielleicht sollte man mal versuchen testweise auf einem der Rechner ein neueres JRE zu installieren. Da ist dann auch das entsprechende Applet-plugin.
Die JREs gibt es auf http://www.java.com
Wenn ich mich richtig erinnere, funktionierten bei Java 1.4 nicht mehr die Lotus Applets.
Aber vermutlich tuts ja eine Java1.3 Runtime.
Bei mir wurden jedenfalls vor 2 Monaten selbstgeschriebene, in Domino eingebundene Applets gecached.
Dieser caching Prozess kannst du nicht programmatisch steuern. Bei installierten Plug-In ist in der Systemsteuerung ein Icon Sun Java Plug-In. Dort kann man (zumindest unter dem hier installierten 1.4 plug-in) die cache-Größe ändern, den cache leeren, etc. Weiss aber nicht, ob es das schon für 1.3 gabe.
Du benötigst nicht das gesamte JDK (dev kit) sondern nur das JRE (runtime).

Ich bin mir nicht ganz sicher, ob es möglich ist die Applets lokal zu laden (Vorschlag des jungen Manns mit dem chemischen Namen).  Vielleicht gibt es da Probleme mit der Applet-Security, wenn die versuchen, Kontakt mit dem Server aufzunehmen (zum Datenaustausch, Domino Applets machen das).

Ansonsten sind diese Domino Applets Schrott aus dem Technologie-Museum.
Applets und GUI-Java allgemein wurden in der Zwischenzeit heftigst kritisiert. Durch neuere Entwicklungen ist das wieder ein gangbarer Weg. Diese Entwicklungen sind aber nicht in den Notes-Applets drinne.

Vielleicht kannst du den Kunden überreden den Unsinn durch eine DHTML Oberfläche zu ersetzen.

[animate]

Ich bin mir nicht ganz sicher, ob es möglich ist die Applets lokal zu laden (Vorschlag des jungen Manns mit dem chemischen Namen).  Vielleicht gibt es da Probleme mit der Applet-Security, wenn die versuchen, Kontakt mit dem Server aufzunehmen (zum Datenaustausch, Domino Applets machen das).

Du hast vollkomen Recht. Ich bin nicht so firm in Applet-Security, aber diese Applets dürfen wohl nur auf der Maschine "arbeiten", auf der sie residieren, oder?

heute morgen ist mir aufgefallen, dass ich eine neue Gestaltung meiner MailDB habe, zumindest im Web. Das ganze heißt iNotes WebAccess und kein Applet weit und breit zu sehen. Vielleicht forschst du mal in diese und in die DHTML-Richtung

[Glombi]

Hi an alle: vielen Dank erstmal für Eure Antworten.
Axel: Leider befindet sich der "Unsinn" in der R5 Notes Mailschablone. Wie soll ich dem Kunden (als IBM Business Partner) verklickern, dass das alles Müll ist?

Das ganze gipfelt noch darin, dass bei einigen nicht die JVM von Microsoft sondern von Sun installiert ist. Und dann kracht es erstmal richtig. Es gab bereits Datenverlust, da sich alle gestarten Browserfenster verabschieden, falls ein User "versehentlich" mal in sein Mail per Browser gegangen ist.
Also habe ich jetzt zunächst mal einiges von Java Applets in HTML umgewandelt.

Bei denen, die die MS JVM benutzen, ist halt die Performance wg. Java Applets schlecht. Ich werde Deinem Tipp mal nachgehen...

Gruß
Andreas

[Axel Janssen temp]

Hallo Andreas,

Axel: Leider befindet sich der "Unsinn" in der R5 Notes Mailschablone. Wie soll ich dem Kunden (als IBM Business Partner) verklickern, dass das alles Müll ist?

Z.B. damit, dass das zu der Zeit der Entwicklung in Domino5 für einige Leute wie ein vielversprechender langfristiger Ansatz aussah, der sich dann aber im zuge einer schnellen Entwicklung gegenüber anderen Ansätzen als unterlegen erwies.
In Domino6 sind diese Applets doch weitgehend weg, oder?

Das ganze gipfelt noch darin, dass bei einigen nicht die JVM von Microsoft sondern von Sun installiert ist. Und dann kracht es erstmal richtig. Es gab bereits Datenverlust, da sich alle gestarten Browserfenster verabschieden, falls ein User "versehentlich" mal in sein Mail per Browser gegangen ist.

Es ist eigentlich mehr eine Frage der Java-Version als dem VM-Hersteller. Obwohl sich Sun wirklich die größte Mühe gibt abwärtskompatibel zu sein, ist es den Schnellschiessern von Iris gelungen, Applets zu produzieren, die nicht Java1.4 tauglich sind. Ich habs nicht mit einer IBM1.4er VM versucht, vermute aber, dass es die gleichen Probleme gibt.

Mit 1.3er VMs funktioniert es (Arbeitshypothese). VMs haben dramatische Entwicklungen in den letzten Jahren gemacht. Ich würd das mal ausprobieren.
 
Ich vermute sehr stark, dass es an meiner neuen Lieblingsschwäche von Domino - dem nicht JAXP-Standard konformen xml-Parser (in xml4j.jar) - liegt. Java_for_xml wurde in Java1.4 Bestandteil von core Java (die Klassen in der "normalen" Java Virtual Maschine).  
Deshalb kommt es vermuglich zu diesen crashs mit 1.4er VMs. Es gibt Namenskonflikte zwischen den 1.4VM-Java-xml Klassen und den den IRIS-java--xml-Klassen aus XML4j.jar. Solche Konflikte sind auch an anderen Stellen nicht-unproblematisch in Java. Das ist aber ein grundlegendes Problem jeder Software, die auf "Komponenten" (hier: die jars) beruht. Die Software setzt  diese Komponenten voraus und sobald dann 2 Komponenten mit gleichen vollqualifizierten Namen aber unterschiedlichen Inhalt  vorliegen (javax.xml.sax.Parser) kann es zu Chaos kommen. Das ist das gleiche Phänomen wie die MS-dll-Hölle.
Die Diskussionen über die jar-Hölle kocht immer höher und es gibt wohl auch theoretische Lösungsansätze.    
Im Subsystem xml wurde dieses Problem stark durch eben jenen JAXP Standard entschärft, der für unterschiedliche Xml-Parser-Implementierungen eine standardisierte Schnittstelle schafft, über das sie angesprochen werden.

Das ist aber wirklich ein Fehler von IRIS und nicht von SUN.

Also habe ich jetzt zunächst mal einiges von Java Applets in HTML umgewandelt.

So mach ichs auch immer, ausser es geht nicht anders.

[Axel Janssen temp]

Du hast vollkomen Recht. Ich bin nicht so firm in Applet-Security, aber diese Applets dürfen wohl nur auf der Maschine "arbeiten", auf der sie residieren, oder?

Nicht ganz. Sie arbeiten ja auf dem client.
Nur öffnen die Notes-Applets während der Laufzeit Socket-Connections zum host.
Und das ist - wenn mich nicht alles täuscht - mit der Standard Applet Security nur zu dem Host möglich, von dem die Applets geladen wurden (gilt aber auch für von ursprünglich von diesem host gecachte Applets).  

Man kann durch signieren von Applets, bearbeiten des policy files, etc. die Standard Applet security etwas flexibler gestalten. Die entsprechenden Tools finden sich im jdk, eine brauchbare Dokumentation im Java Tutorial von Sun: http://java.sun.com/docs/books/tutorial/security1.2/index.html

Gruß Axel

[Glombi]

Ich habe dem Kunden jetzt empfohlen, eine testumgebung für Domino Web Access (iNotes) aufzusetzen. Das basiert ja auf DHTML und XML und ich hoffe, dass dort alle glatt läuft.
Die ganze R5 Mailschablone (Notes & Web) auf HTML umzustellen, das kann es ja wohl nicht sein.

Danke nochmal für alle Tipps!
Andreas

[Axel_Janssen]

Ich habe dem Kunden jetzt empfohlen, eine testumgebung für Domino Web Access (iNotes) aufzusetzen. Das basiert ja auf DHTML und XML und i

Das ist sicher die beste Lösung.
Applets spielen zur Zeit wirklich eine wirklich marginale Rolle in der Java Programmierung, wobei sich die Stimmung bei GUI-Programmierung allgemein in den letzten 3 Monaten ein wenig verbessert hat.  

noch mal zurück, weil das in der Hektik der Woche ein bischen untergegangen ist:
- Wenn du dir den Quelltext der von Domino erzeugen html Seite mit dem Applet anschaust, dann gibt es da einen Applettag, wo vermutlich irgendeins der folgenden Properties auf eine .jar Datei zeigt.

Handbuch der Javaprogrammierung:
001 <APPLET CODE="Hello.class" WIDTH=300 HEIGHT=200>
002 Hier steht das Applet Hello
003 </APPLET>

Parameter Bedeutung  
CODEBASE Hier kann ein alternatives Verzeichnis für das Laden der Klassendateien angegeben werden. Fehlt diese Angabe, wird das Dokumentenverzeichnis genommen.  
ARCHIVE Angabe eines JAR-Archivs, aus dem die Klassendateien und sonstigen Ressourcen des Applets geladen werden sollen. Ein Beispiel zur Verwendung des ARCHIV-Parameters ist in Abschnitt 50.6 bei der Vorstellung von jar zu finden.  
OBJECT Name einer Datei, die den serialisierten Inhalt des Applets enthält  
ALT Alternativer Text für solche Browser, die zwar das Applet-Tag verstehen, aber Java nicht unterstützen  
NAME Eindeutiger Name für das Applet. Er kann zur Unterscheidung mehrerer, miteinander kommunizierender Applets auf einer Web-Seite verwendet werden.  
ALIGN Vertikale Anordnung des Applets in einer Textzeile. Hier kann einer der Werte left, right, top, texttop, middle, absmiddle, baseline, bottom oder absbottom angegeben werden.  
VSPACE Rand über und unter dem Applet  
HSPACE Rand links und rechts vom Applet  

Die jars der Notes-Standard Applets finden sich meines Wissens auch in der lokalen NotesClient Installation.
Natürlich kann man auf die verweisen. Ganz einfach ist es, wenn die Notes-Installationspfade im gesamten Unternehmen gleich ist. Ansonsten muß man das vielleicht irgendwie programmatisch ermitteln und via computed Text setzen (zur Not mit WinApi Programmierung über die Registry.
Oder du kannst sie auf allen Rechnern in einen bestimmten Pfad kopieren.

Dann werden aber vermutlich aus den oben genannten Gründen security exceptions auftreten. Applets sind "verteilter code", der übers Netzwerk und möglicherweise übers Internet geladen wird. Applets laufen in einer sicheren, gemanagten Umgebung. Sie können nicht so einfach socket-connections zu irgendwelchen Servern aufbauen (es sei denn es ist der Server, von dem sie geladen wurden).
Um diese restriktive ECL-verwandte Security zu umgehen, gibt es im jdk Tools zur Signierung von Applets oder zur Bearbeitung globaler  Sicherheitsrichtlinien (auch auf einen host beschränkt).
Signierte Applets sind die bessere Lösung. Der User wird gefragt, ob er dem Applet x von Organisation y die Operationen a, b, ..., n genehmigen will.
Die angesprochenen Signier und Richtlinienveränderungs-Tools werden en detail hier beschrieben: http://java.sun.com/docs/books/tutorial/security1.2/index.html
Es ist eigentlich nicht so schwierig.

Gruß Axel