Am Dienstag, 16. März 2004 21:39 schrieb Bodo Kaelberer:
Das GUI soll "multiuser fähig" werden, nun denken ich das es ein kleiner Performanzgewinn sein könnte, wenn der Client keine Rechenoperationen mehr machen muss.
Reden wir hier von 1 bis 5 Users oder von 1000? (-;
Ich denke so bis 50 ist realistisch?? Habe ich mir ehrlich gesagt noch nicht genau überlegt! Je mehr je besser :) Was ist den bei vielen Usern besser, die Last auf den Server oder im Client? IMHO der Server.
Mal nebenbei: Ich habe mit JDBC nie etwas gemacht. Allgemein hat man bei einfachen Client-Server Implementierungen (z.B. Browser <-> PHP) immer das Problem, daß man keiner Information, die vom Browser kommt, trauen kann.
Joo, das kenne ich von Perl ;)
Was bietet JDBC an Sicherheitsmechanismen für die Übertragung, z.B. gegen manipulierte Statements? Oder in anderen Worten: Wer verhindert, dass ein manipulierter Client ein "DROP TABLE kundendaten" schickt?
Gute Frage, per default wird alles in Klartext sein... (???)
Und wie funktioniert die Anmeldung? Die Zugangsdaten werden ja wohl kaum im Applet stehen. Oder doch?
Es wird kein Applet geben. Auf dem Internetserver wird nur Apache mit mod_jk/tomcat laufen. Mysql natülich auch. Nur der Shop direkt ist manipulierbar, z.B. in den jemand versucht die Servlets zu steuern. Der Shop Besucher erwartet so oder so eine verschlüsselte Verbindung bei der Eingabe seiner Daten. Da kommt man ohne https nicht rum. Das UI muss ich mit Swing machen (leider gibt's QT nur als eval für M$) und ist zum Artikel rein hacken in eine "lokale DB" gedacht. Der Abgleich mit der DB auf dem I-Server wollte ich mittels SSH und XML lösen, vielleicht auch mit sql.txt. Das würde mit putty bzw pscp auf M$ ganz gut klappen. Mit Java gibt es allerdings auch eine API, womit man RSA & Co. benutzen kann. Ich bin wiedermal für alle Vorschläge und Hints zu haben, ist noch alles in der Planung. Ciao Andre