Re: JFritz mit SQL

[Christian Klein]

Die Daten müssen auf jeden Fall in eine DB, das ist ein großer Schritt
zur Lösung diverser Probleme.

HSQLDB ist gut. Ich würde das dann so wie Robert sehen: Ist eine
Datenbank (HSQLDB im Server Modus, MySQL, ...) in irgendeiner Form beim
Start von JFritz konfiguriert (Startparameter, ini-Datei), so wird diese
verwendet (TCP/IP), ansonsten HSQLDB im "In-Process" Modus.



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Jfritz-devel mailing list
Jfritz-devel@...
https://lists.sourceforge.net/lists/listinfo/jfritz-devel

[Arno Willig]

Hi Developers!

Wenn JFritz  netzwerkfähig werden soll, wäre die vernünftigste Lösung
einen JFritz-Server zu implementieren, der die Daten von den Boxen
abholt und bei dem sich die Client authentifizieren müssen, um ihren
Teil der Daten zu bekommen.
Sämtliche Kommunikation zwischen den Clients und den Boxen läuft über
den Server.

Folgendes wäre also zu tun, um ein Client-Server-Konzept zu realisieren:

- Server erhält alle Klassen, die zur Box-Kommunikation notwendig
- Client erhält GUI und Authentifizierungsmöglichkeit beim Server
- Client und Server können sich über SOAP unterhalten (ein Protokoll,
bei dem XML-Dateien ausgetauscht werden, kann man sehr schön mit Java
implementieren).
- Der Server kann als alternatives Backend zu den XML-Dateien auch JDBC
benutzen, um in *beliebigen* relationalen Datenbanken zu speichern.

Was haltet ihr davon?

Ciao, Arno




-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jfritz-devel mailing list
Jfritz-devel@...
https://lists.sourceforge.net/lists/listinfo/jfritz-devel

[Markus Moises]

Hallo zusammen,

um mich hier mal kurz einzuschalten:
Die Lösung die Arno vorgeschlagen hat ist technisch einwandfrei, aber
eben nur wenn man ein Server/Client Konzept verfolgen will.
Ich denke allerdings dass das an der Relität ein wenig vorbeiläuft.

Das typische Anwendungs-Szenario dürfte so aussehen:
- 1 JFritz Hauptnutzer,  der sich alle Telefonate abholt und ein
Telefonbuch pflegt
- 2-3 weitere Nutzer, die nach Bedarf Telefonate abholen und entweder
kein Telefonbuch pflegen, oder nur wenige Nummern eintragen.

Im Moment gibt es dabei folgende Probleme:
- Die Nutzer haben  jeweils ihr eigenes Telefonbuch, ohne Möglichkeit
zur Synchronisation
- Beim Löschen der Telefonliste auf der Box kommt es evtl. bei einigen,
schlimmstenfalls bei allen Nutzern zu Datenlücken

Die Probleme die ich bei Arnos Lösung sehe:
-  Das Ganze ist eine Always-On Lösung, ist der Server nicht verfügbar,
kann der Client nicht benutzt werden.
- Was mit dem Telefonbuch des Clients passiert ist noch nicht beschrieben.

Besonders Punkt 1  sehe ich ale extrem problematisch, da man im
typischen Familien-Kleinstnetzwerk nicht davon ausgehen kann dass ein
Rechner immer läuft.
Ich persönlich kann mich mit dem Server/Client Konzept also nicht
anfreunden.

Ich sehe 2 Möglichkeiten um das Ganze etwas zugänglicher zu machen:
- Externe Datenhaltung (Datenbank, Server, idealerweise die Fritzbox
selbst) zumindest für das Telefonbuch, evtl. auch die Anrufdaten
- Datensynchronisation zwischen verschiedenen JFritz Instanzen im
lokalen Netzwerk

Mein Wunschkandidat wäre Vorschlag Nummer 2, mit dem einzigen
Unterschied zwischen den Clients dass nur ein vorher konfigurierter
masterclient die Möglichkeit hat, die Anrufliste auf der Box zu löschen.


Ok, der Nutzer hat gesprochen, vielleicht könnt ihr mit den Vorschlägen
was anfangen ;-)

Viele Grüße, Markus




Arno Willig wrote:
> Wenn JFritz  netzwerkfähig werden soll, wäre die vernünftigste Lösung
> einen JFritz-Server zu implementieren, der die Daten von den Boxen
> abholt und bei dem sich die Client authentifizieren müssen, um ihren
> Teil der Daten zu bekommen.
> Sämtliche Kommunikation zwischen den Clients und den Boxen läuft über
> den Server.




-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Jfritz-devel mailing list
Jfritz-devel@...
https://lists.sourceforge.net/lists/listinfo/jfritz-devel

[Peter Körner]

Hi

> Ich persönlich kann mich mit dem Server/Client Konzept also nicht
> anfreunden.
Wie wäre es mit einem kombinierten S/C-System?
Beim Startup fragt jFritz im Netzwerk per Broadcast nach einem Server
und verbindet sich zu dem, dann Synchronisiert er die Daten seit der
letzten Aktivierung vom dem Server und startet selbst im Clientmodus.
Ist kein Server verfügbar startet jFritz selbst im Servermodus und
stellt seine Daten zur Verfügung bzw. synchronisiert von der Box.
Fällt ein Server im laufe einer Client-Session aus müssen die
verbliebenden Clienten einen neuen Server bestimmen, das muss auch
irgendwie per Broadcast gehen, idealerweise nach dem "wer zuerst kommt
malt zu erst"-Prinzip mit Timestamps.
Das macht die ganze Sache natürlich um einiges komplexer, aber vllt
gibts ja auch irgendwo schon ein fertiges Framework für sowas. Kenne
mich da bei Java nich so gut aus..

Gruß, Peter



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Jfritz-devel mailing list
Jfritz-devel@...
https://lists.sourceforge.net/lists/listinfo/jfritz-devel

[Brian Jensen-2]

Arno Willig wrote:

> Wenn JFritz  netzwerkfähig werden soll, wäre die vernünftigste Lösung
> einen JFritz-Server zu implementieren, der die Daten von den Boxen
> abholt und bei dem sich die Client authentifizieren müssen, um ihren
> Teil der Daten zu bekommen.
> Sämtliche Kommunikation zwischen den Clients und den Boxen läuft über
> den Server.
>
> Folgendes wäre also zu tun, um ein Client-Server-Konzept zu realisieren:
>
> - Server erhält alle Klassen, die zur Box-Kommunikation notwendig
> - Client erhält GUI und Authentifizierungsmöglichkeit beim Server
> - Client und Server können sich über SOAP unterhalten (ein Protokoll,
> bei dem XML-Dateien ausgetauscht werden, kann man sehr schön mit Java
> implementieren).
> - Der Server kann als alternatives Backend zu den XML-Dateien auch
> JDBC benutzen, um in *beliebigen* relationalen Datenbanken zu speichern.

Ok, ich habe mir Zeit genommen, um über diesen Vorschlag und auch über
die beiden anderen nachzudenken Es sind wirklich gute Ideen
vorgeschlagen worden.

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

Leider wirds nicht klappen, das Telefonbuch und die Anrufliste direkt
auf die Box zu speichern. Zum einen enthält das Telefonbuch der Box zu
wenige Felder, um das Telefonbuch in JFritz nachzumachen. Zum anderen
hat die Box nur eine kleine Menge an Arbeitsspeicher. Bei langen
Anrufslisten könnte ich mich vorstellen, dass der Speicher der Box
überlastet wird (abgesehen von der Überlastung durch die vielen
Verbindungen zur Box) .

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

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

Es gab für mich zwei Gründe, warum JFritz auf eine Datenbank wechseln
sollte. Eins, mit einer Relationalen Datenbank kann sehr leicht neue
Filter bauen, die ich für sehr nützlich halte. Aber ich bin letztens auf
XQuerry und XQJ aufmerksam gemacht, die SQL-ähnliche Features für
XML-Dateien anbieten. Zwei, ich halte es für nicht sehr klug, die ganze
Anrufliste auf Dauer in Arbeitsspeicher zu halten(ich stelle mir vor,
die Listen bei einigen könnten sehr groß werden). Ich weiß allerdings
nicht, wie gerecht diese Schlussfolgerung von mir ist. Ich blieb vorerst
dabei, jfritz soll auf eine Datenbank umsteigen.

Es scheint so, dass eine Netzwerkfähige  Version von JFritz doch
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.
Heißt das, dass du vielleicht zurück kehrst  :-)  (Mit noch einem
Entwickler könnten wir wirklich was schönes rausbringen)

cheers,
    Brian  

 --
Brian Jensen

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



-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Jfritz-devel mailing list
Jfritz-devel@...
https://lists.sourceforge.net/lists/listinfo/jfritz-devel