Re: [Jfritz-devel] =?ISO-8859-15?Q?Netzwerkf=E4higkeit_von_J?= =?ISO-8859-15?Q?Fritz?=

[Brian J. <je...@in...>]

Arno Willig wrote:
> Wenn JFritz  netzwerkf=E4hig werden soll, w=E4re die vern=FCnftigste L=F6=
sung=20
> einen JFritz-Server zu implementieren, der die Daten von den Boxen=20
> abholt und bei dem sich die Client authentifizieren m=FCssen, um ihren=20
> Teil der Daten zu bekommen.
> S=E4mtliche Kommunikation zwischen den Clients und den Boxen l=E4uft =FC=
ber=20
> den Server.
>
> Folgendes w=E4re also zu tun, um ein Client-Server-Konzept zu realisier=
en:
>
> - Server erh=E4lt alle Klassen, die zur Box-Kommunikation notwendig
> - Client erh=E4lt GUI und Authentifizierungsm=F6glichkeit beim Server
> - Client und Server k=F6nnen sich =FCber SOAP unterhalten (ein Protokol=
l,=20
> bei dem XML-Dateien ausgetauscht werden, kann man sehr sch=F6n mit Java=
=20
> implementieren).
> - Der Server kann als alternatives Backend zu den XML-Dateien auch=20
> JDBC benutzen, um in *beliebigen* relationalen Datenbanken zu speichern=
.
Ok, ich habe mir Zeit genommen, um =FCber diesen Vorschlag und auch =FCbe=
r=20
die beiden anderen nachzudenken Es sind wirklich gute Ideen=20
vorgeschlagen worden.

Also wie ich die Sache sehe, soll jfritz auf jeden Fall eine c/s=20
Architektur haben. Wie der Markus schon gesagt hat, ist es nicht=20
empfehlenswert einen  zentralen Datenbestand und dazu "dumme" Clients zu=20
verwenden (Das h=E4tten wir  eigentlich mit  hsqldb vor  :-( ).  Sch=F6ne=
r=20
w=E4re es, wenn es lediglich einen Sync zwischen  Client und  Server g=E4=
be.=20
Dadurch k=F6nnen die Clients noch ohne den Server funktioneren (kriegen=20
blo=DF keine neue Anrufe / kontakte vom Server).

Leider wirds nicht klappen, das Telefonbuch und die Anrufliste direkt=20
auf die Box zu speichern. Zum einen enth=E4lt das Telefonbuch der Box zu=20
wenige Felder, um das Telefonbuch in JFritz nachzumachen. Zum anderen=20
hat die Box nur eine kleine Menge an Arbeitsspeicher. Bei langen=20
Anrufslisten k=F6nnte ich mich vorstellen, dass der Speicher der Box=20
=FCberlastet wird (abgesehen von der =DCberlastung durch die vielen=20
Verbindungen zur Box) .

Was ich auf jeden Fall f=FCr n=F6tig halte, ist eine Zentrale=20
Authentifizierungsdienst. Im Fritz!box kann ja nur ein Passwort=20
hinterlegen. Viele bentutzen JFritz am Arbeitsplatz (selbst eine Firma=20
im selben Haus wie meine Firma benutzt JFritz :-) ), und die wollen es=20
sicherlich nicht haben, dass Alle Mitarbeiter auf die Box zugreifen=20
k=F6nnen und genauso wenig, dass die Mitarbeiter gegenseitig auf die=20
Anrufe der anderen zugreifen k=F6nnen. Mit einem Authenfizierungsdiesnt=20
k=F6nnte man daf=FCr sorgen, dass Jeder nur bestimmte Daten zugreifen kan=
n.

Wie die Daten gespeichert werden bzw wie die Clients mit dem Server=20
kommunizieren, steht f=FCr mich noch offen. Ich finde jedoch, dass JFritz=
=20
nicht automatisch als Server funktionieren soll. Die User sollen dar=FCbe=
r=20
entscheiden, ob JFritz die Daten "frei gibt" oder nicht. Ich kenne mich=20
ein wenig mit JAXM und JAX-RPC aus, die k=F6nnten wir mit mittlerem=20
Aufwand f=FCr die Interprozess-Kommunikation einsetzen.

Es gab f=FCr mich zwei Gr=FCnde, warum JFritz auf eine Datenbank wechseln=
=20
sollte. Eins, mit einer Relationalen Datenbank kann sehr leicht neue=20
Filter bauen, die ich f=FCr sehr n=FCtzlich halte. Aber ich bin letztens =
auf=20
XQuerry und XQJ aufmerksam gemacht, die SQL-=E4hnliche Features f=FCr=20
XML-Dateien anbieten. Zwei, ich halte es f=FCr nicht sehr klug, die ganze=
=20
Anrufliste auf Dauer in Arbeitsspeicher zu halten(ich stelle mir vor,=20
die Listen bei einigen k=F6nnten sehr gro=DF werden). Ich wei=DF allerdin=
gs=20
nicht, wie gerecht diese Schlussfolgerung von mir ist. Ich blieb vorerst=20
dabei, jfritz soll auf eine Datenbank umsteigen.

Es scheint so, dass eine Netzwerkf=E4hige  Version von JFritz doch=20
wichiger ist als ich dachte  :-) .

Mal sehen, was der Robert dazu zu sagen hat.

@Arno: Du hast in letzter Zeit viele Mails in der Mailingliste gepostet.=20
Hei=DFt das, dass du vielleicht zur=FCck kehrst  :-)  (Mit noch einem=20
Entwickler k=F6nnten wir wirklich was sch=F6nes rausbringen)

cheers,
    Brian =20

 --=20
Brian Jensen

Blog and other things: http://home.in.tum.de/~jensen/blog/