@mk-soft
Ich denke doch, weil :
1. SQLite bei PB dabei ist - es aber noch keinen PB-SQLite-Server gibt. An einer ganz anderen Baustelle würde ich mir z.B. einen Filter via Bitfeld-ID wünschen. So etwas gibt es aber nicht und die Quelltexte anderer DB sind nicht in meiner Sprache.
3. SQLite ist die mit Abstand am weitesten verbreitete Datenbank - weltweit - nicht nur im PB-Umfeld.
2. Abgesehen davon ist das wovon ich schreibe noch lange keine PB-Realität und selbst hootie, kinto und remoteStorage stecken noch in den Kinderschuhen. Das sollte Dich also nicht abschrecken.
4. Mit einem SQLite-Server würdest Du das Fundament für diese Idee erweitern bzw für PB schaffen.
5. Wenn Du den Source frei gibst und nicht an Dokumentation sparst können auch Leute wie ich ihn in die Richtung ausbauen.
Dass es grundsätzlich einen Bedarf an der Kombination Embedded und Server gibt zeigt sich ja u.a. gerade daran, dass es sie schon gibt.
Allerdings muß ich zugeben, dass ich mich über einen Pouch-Clone bzw minimongo-Clone oder etwas in der Art mehr freuen würde.
Damit meine ich einen embeded Stellvertreter für eine DB die gut synchronisiert (Stichwort verteilte DB)
@TroaX
Jein, es kommt nicht nur darauf an, wie viel Arbeit man in die Serversoftware (muß nicht zwangsläufig eine Webanwendung sein) stecken will.
"no Backend & offline first" will ja eher weg von aufwendigen Backends. Es läuft eher in Richtung synchronisierende DB-Server und ggf. vorgeschalteter schlanker Middleware mit weitsichtiger API und Plugin-Schnittstelle.
Im Moment holt sich z.B. PHP die Daten von einem MySQL-Server. Dabei ist vieleicht sogar eine DB-Abstarktionsschicht mit im Spiel. Dann wandelt PHP sie bei einer Single-Page-Anwendung in JSON und schleift sie durch einen Apache.
Viel einfacher wäre es doch wenn der Client (kann muß aber kein Browser sein) die Daten (kann muß aber kein JSON sein) direkt vom (wie auch immer gearteten) DB-Server (oder einem embeded Stellvertreter) holen würde.
Solange die Server sich synchronisieren könnte jeder einen bei sich haben oder zumindest so tun als ob - z.B. SQLite (embeded)
Ein synchronidierender PB-DB-Server könnte die gesamte Logik enthalten, über Plugins abdecken oder auf andere Server abwälzen (z.B. Mailserver, PDF-Genrierung, Konvertierung, ...).
Eine Middleware wäre gar nicht mehr notwendig.
Wenn es nur um eine Person geht reicht ein portable Server bzw embeded Stellvertreter.
Wenn es nur um einen geschlossenen Personenkreis geht reicht ein zentraler Server solange eine Verbindung besteht.
Besser wäre es wenn alle einen portabel bzw embeded Server hätten der sich sobald eine Verbindung besteht mit dem/den zentralen Server(n) abgleichen würde.
ggf. Mehrzahl weil:
Ich war z.B. an Weihnachten bei meinem Sohn zu Besuch und habe da eine Menge Photos via WhatsApp bekommen.
Es wäre doch toll gewesen wenn er die einfach nur auf seinem Server für mich hätte frei schalten müssen und mein portable Server hätte sich die Bilder geholt. Noch besser wäre es wenn mein Heim-Server das gleiche bei unserem nächsten Telefonat tun könnte. Das sollte natürlich auch für andere Dinge z.B. ein Link zu einem Thema über das wir sprechen gehen.
Bei meinem letzten Job hatte ich viel mit Friseuren zu tun. Du glaubst nicht wieviele davon nicht in der Lage sind eine Mail zu schreiben. WhatsApp geht aber immer. Das ist so schön einfach, plattformunabhängig und funktioniert auch offline - synchronisiert sich mit dem Server sobald eine Verbindung besteht.
Ich denke in die Richtung wird sich in Zukunft viel tun. Da werden sich alle Großen und eine Menge Start-Up's drauf stürzen. Dann werden Reviere erobert und verteidigt - z.B. werden es sich Anbieter mit einem attraktivem Angebot leisten können ihr eigenes Süppchen zu kochen statt auf freien Basis-Standards aufzubauen. Spätestens dabei wird sich die Spreu vom Weizen trennen. Und irgendwann (nachdem der Kuchen aufgeteilt wurde) gibt es neue Standards und Basis-Standards. Im günstigsten Fall dürfen dann z.B. die Leute von Hoodie mit am Tisch sitzen.
Mitspielen dürfen wir immer. Im Moment haben wir sogar noch eine Chance.
Eine ganz andere Spielart ist "einfach im Offline-Modus eine lokale Datei zu nutzen".
Das gibt es z.B. bei GoogleMaps. Das kann ich offline nitzen wenn ich mir vorher die passenden Kartenausschnitte herunter geladen habe. Bei einer anderen Anwendung muß ich hinterher übertragen - je nach dem copy oder sync.
Zum Thema Firebase habe ich übrigens noch etwas. Das wäre dann auch ein Beispiel, dafür, dass Android- und iOS-Clients auch in Java bzw Objective-C geschrieben sein können. Hier wird zur Abwechslung mal der PC-User in den Browser gezwungen. Singel-Page-Webanwendung, JSON, etc sind zwar momentan erste Wahl. Das liegt aber wohl auch daran, dass Javascript z.Zt. in dem Bereich auch erste Wahl ist. Es wäre schön wenn PB in dem Bereich mitspielen könnte.
https://codelabs.developers.google.com/ ... ase-web/#1
https://github.com/firebase/friendlychat