Laverna: Mit nicht-kommerziellen Speicher synchronisieren

Oder Eigene Cloud...

Schau dir vole.cc an. Sie haben einen benutzerdefinierten Go-basierten Server, der Inhalte in Dateien speichert. Sie könnten sich wahrscheinlich einfach daran anschließen, um eine einfache lokale Speicherung zu ermöglichen.

Ja, das Anschließen an eine eigene Cloud ist perfekt

Eine Synchronisierung mit OwnCloud wäre interessant.

Eine Bittorrent-Sync-Option wäre auch schön.

+1 für eigene Cloud

Wie @michielbdejong über StackEdit geschrieben hat , könnte man darin interessante Ansätze für einen verallgemeinerten Multi-Provider-Datenspeicherkonnektor finden.

Außerdem ist jetzt auch remoteStorage implementiert .

+1 für eigene Cloud !

+1

+1 Cozy.io, Owncloud, Bittorrent-Sync. Jeder von denen wäre großartig!

Ich denke, dieser Thread zeigt die Notwendigkeit einer standardisierten Methode, die Laverna mit Speicheranbietern verbindet. Jeder hat sein eigenes bevorzugtes Programm zum Hosten personenbezogener Daten. Daran ist nichts auszusetzen, aber jetzt, da die Entwickler brauchbare kommerzielle (Dropbox) und nicht-kommerzielle (RemoteStorage) Mittel dafür bereitgestellt haben, würde ich es vorziehen, dass sie sich auf die Erweiterung anderer Aspekte des Projekts konzentrieren. Benutzern die Tools zur Verfügung zu stellen, um sich selbst zu verbinden, würde auf lange Sicht Zeit sparen.

Ich möchte auch eine Synchronisierung von Google Drive (oder sogar eine Synchronisierung von Google Keep)

+1 - Ich stimme auch @andtheWings zu.

Aber im Moment denke ich, dass das Hinzufügen von 2 Diensten: GoogleDrive (primär, da die meisten Leute es bereits verwenden) und OwnCloud (extensiv genutzte nicht-kommerzielle Dropbox-Alternative) eine sehr große Benutzerbasis abdecken und Laverna-Notizen für viel mehr Leute öffnen würden.

Dies kann die Community wirklich erweitern.

Bitte beachten Sie, dass remoteStorage die Synchronisierung von Google Drive und Dropbox standardmäßig bereitstellt. Schauen Sie unter 5apps.com nach .

_Edit:_ Bittorrent Sync im Browser klingt abenteuerlich.

@almereyda Äh , könnten Sie genauer sein, wie ich meine Notizen über remoteData auf Google Drive mit 5apps.com speichern kann?

@almereyda Wenn Sie mit "out-of-the-box-Synchronisierung" meinen, dass Sie Ihre eigene Kontrolle haben, dann gilt dies auch für OwnCloud.

Aber mein Ziel ist es, die Verwendung von Laverna zu verbreiten und von der breiten Öffentlichkeit leicht angenommen zu werden. Ich glaube, Google Drive ist das fehlende Glied dort. Die meisten Leute haben ein Google-Konto und können ihr Google Drive direkt verwenden, anstatt einen Neustart mit einer anderen Dienstanmeldung und -einrichtung durchzuführen.

Da die meisten Leute hier OwnCloud bevorzugen (einschließlich mir) und es offen/nicht kommerziell ist, würde ich definitiv eine Option dafür empfehlen, die zuerst über Google Drive entwickelt wird.

Ich entschied mich für Laverna, in der Hoffnung, dass es sich zu etwas entwickeln könnte, das Evernone ersetzen kann. Ich verwende OwnCloud, um Dropbox, Google Drive usw. zu ersetzen. Ich habe diese Schritte unternommen, damit ich nicht mehr von diesen Diensten abhängig sein und ihren Bedingungen zustimmen muss. Ich verstehe, dass das Hinzufügen der Option zum Synchronisieren mit Diensten wie Dropbox die Popularität erhöhen würde (und das ermutige ich), aber für mich persönlich passt es nicht.

@SandeepPinge

Hurra!

GDrive für die Massen / Owncloud für die Echten !
imho, Owncloud / GDrive ist eine ausgezeichnete Kombination aus kostenloser / proprietärer Software.

Ich betreibe Laverna auf meinem eigenen Webspace. Warum kann ich die Daten (verschlüsselt) nicht direkt auf dem Webserver speichern? Oder kann ich RemoteStorage auf meinem Webserver implementieren? Ich habe keinen SSH-Zugang!

Ich denke, dass Laverna nicht als gehostete Anwendung gedacht war, sondern lokal läuft und die Dateien lokal speichert. Ich würde auch eine gehostete Lösung bevorzugen, da sie die Synchronisation zwischen Geräten viel einfacher macht.

Lokal?
Wenn ich lokale Notizen möchte, verwende ich notepad.exe.
;-)

Laverna wurde als Unhosting konzipiert, dh die Daten werden standardmäßig lokal im Browser gespeichert. Mehr Infos hier: https://unhosted.org/

"Keiner von uns kann auf Ihre persönlichen Daten zugreifen, weil wir IndexedDB und localStorage verwenden. Tatsächlich werden alle Ihre Informationen nur clientseitig gespeichert."
Dies bedeutet afaik, dass die Daten lokal gespeichert werden (in einem Ordner, auf den der Browser zugreifen kann). Aber man kann Dropbox (und hoffentlich bald andere Alternativen) verwenden, um die Notizen zu synchronisieren.

Alle, bitte beachten Sie, dass remoteStorage jetzt in Cosy Cloud verfügbar ist , sodass Sie ganz einfach Ihre eigene Instanz drehen können.

Da Laverna außerdem RemoteStorage unterstützt, aber es scheint bereits eine alte Spezifikation zu sein, wird daran gearbeitet, es auch in ownCloud zu integrieren.

@michielbdejong @skddc Könnten Sie sich Laverna kurz ansehen und untersuchen, warum die Synchronisierung mit 5Apps fehlschlägt? Es funktionierte, glaube ich, vor der Version 0.10. Haben sie den Client einfach nicht aktualisiert? Wäre es sinnvoll, es submodule machen?

Ich kenne Marionette oder den Quellcode dieser App nicht. Wir sind jedoch immer für Sie da und beantworten alle Fragen, sowohl allgemein als auch für konkreten Code.

Wer auch immer den RS-Support in dieser App unterhält (oder die App im Allgemeinen pflegt): Wir freuen uns sehr, Sie in #remotestorage auf Freenode begrüßen zu dürfen oder in den Foren oder auf GitHub über alles zu chatten.

Ich würde auch Syncthing (https://syncthing.net/) und Seafile (http://seafile.com/en/home/) hinzufügen.

1+ für OwnCloud!

1+ OwnCloud

Eigene Cloud wäre toll.

Eigene Cloud +1

eigenecloud +1

eigenecloud +1
Ich bin in genau der gleichen Situation wie @Putdeksel
Die vollständige Kontrolle über Ihre Notizen durch die Verwendung Ihres eigenen Speichersystems wäre erstaunlich.

Die vollständige Kontrolle über Ihre Notizen durch die Verwendung Ihres eigenen Speichersystems wäre erstaunlich.

Ja, es _ist_ erstaunlich und es ist bereits über den RemoteStorage-Support von Laverna möglich. Sie sind nicht einmal an eine einzelne Server-Implementierung gebunden, aber jeder Server, der das RS-Protokoll spricht, kann Ihre Notizen speichern. ;)

@skddc Ich habe mir

+1 eigeneCloud.

OwnCloud-Sync wäre toll.

+1 für eigene Cloud!

Darf ich allen ownCloud-Benutzern hier etwas vorschlagen:

Für App-Entwickler (nicht nur für diese App) wäre es _viel_ einfacher, ownCloud zu unterstützen, wenn ownCloud ein offenes Protokoll für die Datenspeicherung pro Benutzer unterstützen würde. Diese App unterstützt bereits remoteStorage. Wenn also ownCloud remoteStorage unterstützen würde, würden alle remoteStorage-fähigen Apps automatisch auch mit ownCloud als Remote-Storage-Server funktionieren, anstatt dass Entwickler ihren Apps spezielle ownCloud-Unterstützung hinzufügen müssen.

Daher denke ich, dass es großartig wäre, wenn Sie nachgeben/abstimmen oder RS-Unterstützung für ownCloud selbst beitragen würden!

Nach diesem Gespräch schon seit einigen Jahren muss ich nachgeben
Die neueste Bemerkung von @skddc .

Am 25. Juli 2016 um 14:22 Uhr schrieb Sebastian Kippe [email protected] :

Darf ich allen ownCloud-Benutzern hier etwas vorschlagen:

Für App-Entwickler (nicht nur für diese App) wäre es _viel_ einfacher zu
support ownCloud, wenn ownCloud ein offenes Protokoll für einzelne Benutzer unterstützen würde
Datenspeicher. Diese App unterstützt bereits remoteStorage, also wenn ownCloud wäre
RemoteStorage zu unterstützen, anstatt dass Entwickler spezielle hinzufügen müssen
ownCloud-Unterstützung für ihre Apps, dann würden alle remoteStorage-fähigen Apps
automatisch auch mit ownCloud als Remote-Storage-Server.

Daher denke ich, dass es großartig wäre, wenn Sie RS fragen / dafür abstimmen oder RS ​​beitragen würden
Unterstützung für ownCloud selbst!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Laverna/laverna/issues/6#issuecomment -234938265 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/ABka_MqpAc9pic432ehmtZ58HBUTh2Iyks5qZKqOgaJpZM4BqQ_m
.

Ich +1 dieses Problem!

Hmm, wäre es schwierig, webDAV zu implementieren, da dies als offener Standard angesehen werden könnte, der es ermöglicht, laverna mit Dutzenden verschiedener Speicheranbieter zu verbinden?

Warum nicht die Daten in einem bestimmten lokalen Verzeichnis speichern und die Leute können ihre Daten über Sync-Clients wie Seafile oder ownCloud Desktop-Clients in die Cloud synchronisieren?

Warum nicht die Daten in einem bestimmten lokalen Verzeichnis speichern und die Leute können ihre Daten über Sync-Clients wie Seafile oder ownCloud Desktop-Clients in die Cloud synchronisieren?

Das ist nur in einer möglichen Paketversion der App möglich, aber nicht im Web. Dies ist auch das, was remoteStorage löst und warum es in Laverna verwendet wird.

Hat jemand hier bisher ein ownCloud-Problem zur Integration von remoteStorage geöffnet? Ich kann nur betonen, wie toll das wäre und dass Laverna dann automatisch ownCloud unterstützen würde.

Das ist nur in einer möglichen Paketversion der App möglich, aber nicht im Web. Dies ist auch das, was remoteStorage löst und warum es in Laverna verwendet wird.

Es ist mir nie gelungen, eine voll funktionsfähige RemoteStorage-Synchronisation zu haben. Ich habe es viele Male versucht, und es ist jedes Mal ziemlich schwer, mit allen fertig zu werden. Ich bin mit IndexedDB-Daten nicht so vertraut ...

Ich kenne mich eher mit den DAVs Syncs aus. @wwebfor hat mir gesagt, dass es eine andere Möglichkeit gibt, im Ofen zu synchronisieren, dachte.

Es ist mir nie gelungen, eine voll funktionsfähige RemoteStorage-Synchronisation zu haben. Ich habe es viele Male versucht, und es ist jedes Mal ziemlich schwer, mit allen fertig zu werden.

Sagen Sie, dass es fehlgeschlagen ist, nachdem die Synchronisierung vor einiger Zeit behoben wurde und Sie ein Problem damit geöffnet haben, das nicht zu einem Abschluss kam?

Ich habe keine derartigen Probleme oder Anfragen gesehen, aber ich würde Ihnen gerne helfen! Ich bin mir nicht sicher, was "jedes Mal schwer mit allen umzugehen" bedeutet.

Ich bin mit IndexedDB-Daten nicht so vertraut

Nun, es ist im Grunde die einzige Datenbank, die in modernen Browsern lokal verfügbar ist (außer natürlich localStorage), daher gibt es keine wirklichen Optionen, um etwas anderes zu verwenden.

Sagen Sie, dass es fehlgeschlagen ist, nachdem die Synchronisierung vor einiger Zeit behoben wurde und Sie ein Problem damit geöffnet haben, das nicht zu einem Abschluss kam?

Nein, ich habe bei Gitter nachgefragt und bin zu dem Schluss gekommen, dass ich alle meine Daten in jedem von mir verwendeten Browser bereinigen muss, da es anscheinend in einem sauberen Browser (wo Laverna noch nie verwendet wurde) ordnungsgemäß funktioniert.

Ich bin mir nicht sicher, was "jedes Mal schwer mit allen umzugehen" bedeutet.

Jeder Browser (oder Desktop-Client), den ich verwende, jedes Mal, wenn ich einen davon verwende.

Nun, es ist im Grunde die einzige Datenbank, die in modernen Browsern lokal verfügbar ist (außer natürlich localStorage), daher gibt es keine wirklichen Optionen, um etwas anderes zu verwenden.

Ja, ja, ich verstehe. Aber ich meinte, dass ich diese Art der Datensynchronisierung nicht gewohnt bin.

Klingt für mich nach einem Upgrade-Problem. Also, wenn du schreibst...

Es ist mir tatsächlich nie gelungen, eine voll funktionsfähige RemoteStorage-Synchronisierung zu haben

... bedeutet das, dass es immer noch nicht funktioniert? Wenn das der Fall ist, helfe ich trotzdem gerne.

+1 für webDAV, viel mehr Standard als eine "Owncloud only"-Lösung. Lasst uns offen bleiben, Leute.

Anstatt viele unsinnige neue Hipster-Lösungen wie remoteStorage zu integrieren, warum nicht das bewährte webDav verwenden? Ich meine, was ist der Sinn? Warum zwingen Sie die Benutzer, sich Ihrem Willen zu beugen, wenn der Industriestandard de facto etwas anderes ist?

Ja zu sagen, rs unterstützt dies und das nützt den meisten Leuten wenig. Aber ich möchte nicht noch ein anderes Protokoll verwenden, das mir egal ist. Sie unterstützen kommerzielle Dropbox, aber der Besitz der Notizen bedeutet, dass ich sie nicht auf einem Drittanbieter-Server speichern möchte. Sie wollen einfach nicht verstehen, dass Ihre Software aufgrund ihrer Freundlichkeit und Flexibilität nur überleben wird, wenn die Leute sie benutzen wollen. Stattdessen zielen Sie darauf ab, sie zu etwas zu bewaffnen, das sie nicht tun wollen. Das sind alles Entwickler und technisch versierte Leute, diese einfache Tatsache versteht man einfach nicht.

@technodrome Ich spreche nicht für die Laverna-Entwickler, sondern als remoteStorage.js-Entwickler. Vielleicht ist nicht klar, dass mein Versuch, den Leuten hier zu helfen (ich habe nie etwas anderes versucht, wenn du die Geschichte sorgfältig liest) nicht dasselbe ist, als Leuten zu sagen, dass sie weggehen sollen, weil ihre Meinungen nicht gültig sind oder von jemand anderem gehört werden. Soweit ich sehen kann, ist dies sicherlich der richtige Ort, um sie zu äußern, und ich bin mir nicht sicher, warum Ihr erster Kommentar in diesem Thread so feindselig ist. Lasst uns alle nett zueinander sein, denn das ist für uns alle unbezahlte ehrenamtliche Arbeit!

Stattdessen zielen Sie darauf ab, sie in etwas zu bewaffnen, das sie nicht tun wollen

Ich sehe nicht, wie die kostenlose Bereitstellung einer Open-Source-Software jemanden stark macht. Wenn das alles Entwickler und technisch versierte Leute sind, kann sicher jemand WebDAV-Unterstützung beitragen, wenn es sinnvoll ist?

Schauen wir uns also die Funktionsfähigkeit von WebDAV objektiv an. Hier ist eine (wahrscheinlich unvollständige) Liste der Probleme, die mir einfallen, die gelöst werden müssen, damit WebDAV integriert werden kann. (Dies sind im Grunde genau die Gründe, warum das remoteStorage-Protokoll überhaupt erstellt wurde. Tatsächlich verwendete RS WebDAV ganz am Anfang, und die Autoren entschieden sich, es zugunsten einer einfacheren REST-API zu entfernen, die auf der realen Welt basiert Tests und Erfahrungen damit):

1. CORS

Die Funktionsweise von Browsern besteht darin, dass eine nicht gehostete App wie Laverna über JavaScript direkt mit dem Server verbunden wird. Dies bringt die Einschränkung mit sich, dass der Server Cross-Origin-Resource-Header für alle Anfragen anbieten muss und OPTIONS-Preflight-Anfragen für HTTP-Verben unterstützen muss, die Daten manipulieren können, wie zB POST, PUT, DELETE. Die meisten WebDAV-Server unterstützen dies nicht. Daher wären viele WebDAV-Server standardmäßig nicht mit Laverna kompatibel.

Problem: Selbst wenn man sich nicht darum kümmern würde, dass diese Server inkompatibel sind, wie würde eine App dann erkennen, ob es Support gibt? Dies wird tatsächlich dadurch erschwert, dass Browser absichtlich keine JS-Codedetails darüber angeben, warum die Verbindung fehlgeschlagen ist, sodass es eine Art Erkennungsmechanismus geben müsste. Außerdem muss dem Benutzer erklärt werden, was genau die Ursache sein könnte und dass er möglicherweise den Server wechseln muss, um die App zu nutzen.

Lösung in RS: Das Protokoll erfordert CORS out of the box. Außerdem wird die Erkennung über Webfinger abgewickelt, wo die Benutzeradresse alle Konfigurationsinformationen zurückgeben kann, aber auch zusätzliche Fähigkeiten des Servers bekannt gegeben werden können.

Lösung für einfaches WebDAV/Laverna: Irgendwelche Ideen?

2. Berechtigungen / Autorisierung

Berechtigungen müssen serverseitig und pro Konto in WebDAV verwaltet werden, da so etwas nicht in das Protokoll integriert ist. Zugriffsberechtigungen für bestimmte Ordner sind nicht vorhanden.

Lösung in RS: OAuth 2.0, damit App-Entwickler entscheiden können, auf welchen Teil des Speichers sie Zugriff benötigen, und Benutzer können leicht sehen, welcher Teil dies ist, und in einem einfachen Dialog entscheiden, ob der Zugriff gewährt wird.

Lösung für reines WebDAV/Laverna: Das ist grundsätzlich unmöglich, aber es wäre natürlich möglich, dieses Feature einfach zu überspringen und Laverna freiwillig Zugriff auf alle Daten zu gewähren. Nicht elegant, aber sicher kein Showstopper für die Umsetzung.

3. Offline-/Mobilunterstützung

Dies ist kein spezielles Problem von WebDAV oder allein in der RS-Spezifikation vollständig gelöst. Aber für eine mobilfähige Web-App ist es dennoch ein wichtiger Faktor. Sowohl Desktop- als auch mobile Verbindungen brechen regelmäßig ab, und man möchte nicht, dass ihre Notizen deswegen nicht gespeichert werden. Es muss also eine Art Offline-Speicher verwendet und intelligent mit dem Remote-Server synchronisiert werden (und natürlich ohne erneute Authentifizierung nach jedem Drop, wenn Sie eine gute Benutzererfahrung schaffen möchten).

Hier gibt es zwei Probleme:

Problem 1: Server müssen Etags unterstützen, damit man überhaupt einen Sync-Mechanismus aufbauen kann

Lösung in RS: Dies wird teilweise im Protokoll gelöst, indem ETags sowohl für Verzeichnisressourcen und deren Artikellisten als auch für einzelne Dokumente selbst erforderlich sind. Darauf aufbauend kann man Sync-Mechanismen aufbauen, die HTTP-Header wie zB If-None-Match und Antworten wie zB leere 304 s verwenden, um Dinge anzufordern, die sich nicht geändert haben, und 412 um dies abzulehnen etwas überschreiben, das sich auf einem anderen Gerät zu einem anderen Zeitpunkt geändert hat.

Lösung für einfaches WebDAV/Laverna: Leider ist die Etag-Unterstützung nur ein SOLLTE in der WebDAV-Spezifikation, daher unterstützen viele Server sie nicht und einige bitten ihre Benutzer sogar explizit, die Unterstützung zu deaktivieren, selbst wenn sie sie haben, weil sie implementiert ist auf nicht performante Weise. (Für einen Serverentwickler ist dies eigentlich kein einfaches Problem; das kann ich sicherlich bestätigen). Aber ähnlich wie bei CORS ist dies möglich, so dass die Lösung auch hier darin besteht, die Funktionen zu erkennen und Benutzer zu führen, ihren Server zu konfigurieren oder ihnen mitzuteilen, dass sie zu einem anderen Server wechseln müssen. Glücklicherweise ist dies viel einfacher als bei CORS, da man dies von JS aus erkennen kann, indem man die Antwortheader untersucht.

Problem 2: Schreiben Sie einen tatsächlichen Synchronisierungsmechanismus oder verwenden Sie eine Bibliothek, die einen bereitstellt

Lösung in RS: Sehr früh hat einer der Spezifikationsautoren damit begonnen, eine Referenz-Client-Bibliothek zu erstellen, um dieses Problem für Leute zu lösen, die RS in ihre Apps integrieren möchten. Es wird immer noch gewartet und weiterentwickelt und wurde auf Hunderttausenden verschiedener Verbindungen, Geräte, Betriebssysteme, Browser, in Cordova usw. kampferprobt. Es wird auch in Laverna verwendet. Der erste Commit davon geht auf den November 2010 zurück, also ist das sicherlich keine "neue Hipster-Lösung". Wenn es Fehler gibt, gibt es Leute, die gerne dabei helfen, und jedes Feedback war und ist immer willkommen (daher meine proaktiven Antworten in diesem Thread).

Lösung für einfaches WebDAV/Laverna: Eine mögliche Lösung wäre eine benutzerdefinierte handgerollte Bibliothek. Der Aufwand, einen solchen Code zu erstellen, zu reparieren und zu warten, würde die anderen Probleme, die ich aufgezählt habe, sicherlich in den Schatten stellen, und dennoch ist es natürlich sehr gut möglich, dies zu tun. Die größte Herausforderung, die ich neben buchstäblich tausend anderen zu implementierenden Dingen annehmen würde, ist wahrscheinlich das variable Verhalten von WebDAV-Servern am Ende, insbesondere. ihre Etag-Implementierung. Wenn Sie jedoch eine solche Bibliothek kennen (ich kenne keine, und ich konnte auch keine finden, als ich gerade nochmal nachgesehen habe), wäre es sehr gut möglich, die anderen offenen Probleme irgendwie zu lösen und WebDAV bereitzustellen technische Benutzer.

Bitte entschuldigen Sie und weisen Sie auf eventuelle Fehler oder falsche Tatsachen in dieser Liste hin. Ich habe im Grunde alles aus dem Kopf geschrieben. Ich werde dies bald in das RS-Wiki übertragen und einige Leute bitten, das, was ich geschrieben habe, zu überprüfen / zu bearbeiten, da dies meiner Meinung nach eine ziemlich nützliche Erklärung der Unterschiede zwischen WebDAV und RS ist und wie RS die Dinge löst, die WebDAV hat dies nicht, wenn es um clientseitige Web-Apps geht, die vollständig im Browser ausgeführt werden (was verständlich ist, da die Funktionen der Web-Plattform damals noch nicht wirklich existierten und das gesamte Konzept der Offline-First-Web-Apps nicht so war Ding).

@technodrome Wenn Sie Ihr Ziel, WebDAV-Unterstützung zu erhalten, aufheben) hinzuweisen.

Tut mir leid, aber wenn Sie die Benutzerperspektive des gesunden Menschenverstands nicht verstehen können, weil Sie das Gefühl haben, dass es Ihre Gefühle oder Meinungen verletzt, dann liegt das Problem bei Ihnen. Die für Personen bestimmte Software wird per definitionem von mehr als einer Person verwendet - nicht nur von Ihnen. Daher sollte jeder eingeladen werden, seine Meinung abzugeben, denn Brainstorming und Ideen sind das, was Projekte vorantreibt. Und nach den Leuten zu urteilen, die +1 für WebDav oder andere standardisierte Protokollunterstützung vergeben, bin nicht nur ich.

Sie versuchen, das, was ich gesagt habe, zu verdrehen und die Dinge persönlich zu nehmen, obwohl sie allgemein als persönliche Meinung gedacht waren. Aber auf den Punkt gebracht – wenn ein Entwickler keine standardisierte Methode zum Speichern der Benutzerdaten anbietet, dann ja – er/sie rüstet den Benutzer stark auf, die Präferenzen des Entwicklers zu verwenden.

Technisch versierte Benutzer sind nicht gleich Programmierer. Ziehen Sie keine voreiligen Schlüsse, nur weil es zu Ihrer Rhetorik passt.

Außerdem habe ich klar gesagt, dass ich die Arbeit und Mühe schätze, und das tue ich wirklich. Es bedeutet nur nicht, dass ich blind mit allem einverstanden bin, nur weil Sie es gesagt haben. Es ist mein Recht wie Ihres und es gibt Millionen Möglichkeiten, dieses Problem zu lösen. Natürlich pushen Sie Ihr Produkt, aber lassen Sie uns hier ein bisschen demokratisch sein und eine Wahlfreiheit bieten, die mehr Menschen passt, nicht nur Ihnen.

Während Sie eine ganze Reihe von Gründen aufgelistet haben, warum es nicht funktionieren kann und warum Ihre RS-Lösung das Heilmittel für jeden Schmerz ist, bin ich sicher, dass ein zwischengeschalteter Endpunkt (Go-App?), der als lokaler Daemon (Client, Server) läuft, die Autorisierung übernehmen könnte und ermöglichen eine Vielzahl von Möglichkeiten, nahezu jedes gewünschte Protokoll zu integrieren. Es verursacht sicherlich weniger Kopfschmerzen als die Wartung eines ganzen Stapels von Technologie, die möglicherweise in zwei Jahren vergessen und veraltet ist.

Außerdem sollte mein Kommentar niemandem das Gegenteil beweisen, nur um zu sagen, dass es einen bestimmten Industriestandard gibt und es einen Grund gibt, warum die Dinge zu einem solchen Standard werden. Wenn Sie das nicht verstehen können, gibt es leider keine Argumentation, die Sie von einer anderen Wahrheit als Ihrer überzeugen könnte.

Nun, ich habe gute Argumente auf beiden Seiten gelesen. Schließlich war der Besitz meines Speichers eine Voraussetzung für mich und ging zu turtl, da (verschlüsselter) Speicher auf dem Server Teil des Kerns des Projekts ist.
Wie bereits erwähnt, wenn ein Produkt nicht allen Ihren Bedürfnissen entspricht und es in diesem Fall Gründe dafür zu geben scheint (mit denen man natürlich noch argumentieren könnte), dann suchen Sie nach etwas, das Ihren Bedürfnissen und Anforderungen näher kommt.
Ich bin mir sicher, dass viele Leute damit einverstanden sind, ihre Datei auf Dropbox zu hosten. Sie müssen sich nicht aufregen, insbesondere bei einem Open-Source-Produkt. Ich verstehe und teile die Frustration jedoch, aber Open Source hat viele Geschäftspläne, und manchmal erfüllen sie nicht unsere Anforderungen. Muss nur damit umgehen.

Le 24 février 2017 12:27:33 GMT+00:00, technodrome [email protected] a écrit :

Tut mir leid, aber wenn Sie die Benutzerperspektive des gesunden Menschenverstands nicht verstehen können
weil du das Gefühl hast, dass es deine Gefühle oder Meinungen verletzt, dann das Problem
ist mit dir. Die für Personen bestimmte Software wird per Definition verwendet von
mehr als eine Person - nicht nur Sie. So sollte jeder sein
eingeladen, eine Meinung abzugeben, denn Brainstorming und Ideen sind das, was
treibt Projekte voran. Und nach den Leuten zu urteilen, die +1 für vergeben haben
webDav oder andere standardisierte Protokolle unterstützen nicht nur ich.

Du versuchst, das, was ich gesagt habe, zu verdrehen und die Dinge sogar persönlich zu nehmen
obwohl sie als persönliche Meinung auf einer allgemeinen Ebene gedacht waren. Aber zu
der Punkt - wenn ein Entwickler keine standardisierte Methode zur
Speichern der Benutzerdaten, dann ja - er/sie rüstet den Benutzer stark dazu
Verwenden Sie die Präferenz des Entwicklers.

Technisch versierte Benutzer sind nicht gleich Programmierer. Keine voreiligen Schlüsse ziehen
nur weil es zu deiner Rhetorik passt.

Außerdem habe ich klar gesagt, dass ich die Arbeit und Mühe schätze, und das tue ich wirklich.
Es bedeutet nur nicht, dass ich blind mit allem einverstanden bin, nur weil
du hast das behauptet. Es ist mein Recht wie Ihres und es gibt Millionen Möglichkeiten
wie Sie dieses Problem lösen können. Natürlich drängst du dein
Produkt, aber seien wir hier ein bisschen demokratisch und bieten eine Freiheit von
Wahl, die mehr Leuten passt, nicht nur Ihnen.

Während Sie eine Schiffsladung von Gründen aufgelistet haben, warum es nicht funktionieren kann und warum Ihr
RS-Lösung ist das Heilmittel für jeden Schmerz, ich bin sicher ein Vermittler
Endpunkt (Go App?), der als lokaler Daemon (Client, Server) ausgeführt werden könnte
kümmern sich um die Autorisierung und ermöglichen eine Vielzahl von Möglichkeiten,
Integrieren Sie so ziemlich jedes gewünschte Protokoll. Es bringt sicher weniger
Kopfschmerzen als die Wartung eines ganzen Stapels von Technologie, die möglicherweise oder möglicherweise
nicht vergessen und in zwei Jahren veraltet sein.

Außerdem war mein Kommentar nicht dazu gedacht, jemandem das Gegenteil zu beweisen, nur um zu sagen
Es gibt einen bestimmten Industriestandard und es gibt einen Grund, warum Dinge
zu einem solchen Standard werden. Wenn du das nicht verstehen kannst, fürchte ich
es gibt keine Argumentation, die dich von einer anderen Wahrheit überzeugen könnte
als deine.

--
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/Laverna/laverna/issues/6#issuecomment -282279742

--
Gesandter für Android mit K-9 Mail. Veuillez entschuldigung ma brièveté.

Daher sollte jeder eingeladen werden, seine Meinung abzugeben, denn Brainstorming und Ideen sind das, was Projekte vorantreibt. Und nach den Leuten zu urteilen, die +1 für WebDav oder andere standardisierte Protokollunterstützung vergeben, bin nicht nur ich.

Jawohl! Ich habe genau das gesagt und dann Zeit und Mühe darauf verwendet, darauf hinzuweisen, was meiner Meinung nach gelöst werden muss, um Ihren Wunsch zu erfüllen. Ich habe nichts verdreht, um "meine Agenda" zu passen, und ich lade Sie und alle anderen aktiv ein, auf Fehler in meiner objektiven Analyse hinzuweisen, und ich habe Sie auch eingeladen, bei der Umsetzung Ihrer eigenen Präferenz/Idee mitzuhelfen.

Leider ist es nicht leicht, unter den Vorwürfen in Ihrem Folgekommentar substanzielle Argumente oder neue Fakten zu finden. Aber ein Absatz enthält zumindest eine Idee:

Ich bin mir sicher, dass ein zwischengeschalteter Endpunkt (Go-App?), der als lokaler Daemon (Client, Server) läuft, die Autorisierung übernehmen und eine Vielzahl von Möglichkeiten zur Integration fast jedes gewünschten Protokolls bieten könnte

Also ja, das wäre natürlich theoretisch möglich. Das Problem dabei ist, dass es Ihren eigenen Meinungen und Argumenten im selben Absatz völlig widerspricht:

Es verursacht sicherlich weniger Kopfschmerzen als die Wartung eines ganzen Stapels von Technologie, die möglicherweise in zwei Jahren vergessen und veraltet ist.

Ihre Idee würde genau das bedeuten: Erstellen, testen und warten Sie einen ganz neuen Technologie-Stack ("Client, Server"), damit die Web-App Daten aus der Ferne speichern und geräteübergreifend synchronisieren kann. Abgesehen von dem Problem, diesen ganz neuen Stack zu erfinden und zu warten, wäre es auch ziemlich schwierig, dieses lokale Programm auf all Ihren Geräten auszuführen, vor allem auf mobilen Geräten.

Außerdem sollte mein Kommentar niemandem das Gegenteil beweisen, nur um zu sagen, dass es einen bestimmten Industriestandard gibt und es einen Grund gibt, warum die Dinge zu einem solchen Standard werden.

Dem stimme ich voll und ganz zu! Und ich habe ausführlich erklärt, warum WebDAV tatsächlich nicht zu diesem Standard für clientseitige Web-Apps geworden ist und warum das RS-Protokoll – anfänglich sogar mit WebDAV als API – als neuer Standard geschaffen wurde, um pro Benutzer selbst gehostet zu werden Speicher für genau diese Art von Anwendungen möglich.

Es ist eigentlich ein ziemlich einfaches Protokoll und das Gegenteil eines "Technologiestapels". Falls Sie die kurze Erklärung der Teile nicht gesehen haben, finden Sie sie auf dieser Website . -- Auch in Bezug auf "webDav oder andere standardisierte Protokollunterstützung" ist RS genau das .

Jetzt fühlen, Sie können natürlich negativ über WebDAV nicht eine allzu tragfähige Lösung für die clientseitige Web - Anwendungen zu sein, aber das bedeutet nicht irgendwie die Fakten zur Hand ändern, oder mir eine egoistische Arschloch macht für den Hinweis sie aus. Bitte, bitte , lasst uns das vernünftig diskutieren und persönliche Anschuldigungen raushalten. Ich versuche wirklich nur zu helfen, und es gibt absolut keinen Grund für Negativität. Nochmals: Ich versuche tatsächlich, Ihnen zu helfen, Ihr Ziel zu erreichen, und ich argumentiere definitiv nicht , dass RS eine exklusive Lösung ist. Wenn jemand eine andere Lösung finden kann, die die gleichen Ziele erreicht, dann bin ich der Letzte, der aufgrund persönlicher Vorlieben oder Ideologie dagegen argumentiert.

Laverna kann als Webanwendung nur HTTP als Übertragungsprotokoll unterstützen und benötigt CORS, damit alles funktioniert. Aus irgendeinem Grund schlagen die Leute jedoch Dinge wie BitTorrent Sync oder WebDAV vor, von denen eines nicht über HTTP läuft und von denen keines CORS als Teil seiner Spezifikation hat. Tatsächlich hat ersteres nicht einmal eine Spezifikation, es ist ein proprietäres Protokoll. @technodrome geht sogar so weit, die Verwendung von WebDAV als "

Ich denke, das zeigt wirklich, dass diese Diskussion hauptsächlich von Leuten dominiert wird, die sich "allgemeine Softwarefreiheit" wünschen und die Namen einiger etablierter Protokolle wegwerfen, und nicht von Leuten, die sich ernsthaft mit einer dieser Optionen aus technischer Sicht befasst haben und festgestellt haben, ob sie dies tun sind das richtige Werkzeug für den Job. Nochmals möchte ich @technodrome rufen , der zusätzlich einen Wutanfall bekommt , weil er (verständlicherweise) @skddcs Befürwortung von remoteStorage als Schilling wahrnimmt , der seine eigene Agenda vorantreibt , gleichzeitig ist

Vielleicht sollten wir einfach zugeben, dass es auch nach den drei Jahren, in denen dieses Thema eröffnet wurde, dafür einfach keinen Standard gibt. Was uns drei Möglichkeiten lässt:

1. Wetten Sie auf RemoteStorage, noch kein Standard
2. Verwenden Sie trotzdem WebDAV, benötigen Sie jedoch CORS-Header. Effektiv bedeutet dies nur Unterstützung für NextCloud und ownCloud.
3. Schreiben Sie ein benutzerdefiniertes NextCloud-Plugin mit benutzerdefinierter API

Ad 1: remoteStorage als Protokoll ist ziemlich gut, aber ich glaube, die Client-Bibliothek ist noch nicht da. Tatsächlich war meine letzte Erfahrung mit remoteStorage.js (der Clientbibliothek) nicht gut. Alles funktionierte irgendwie, aber es gab immer noch überall kleinere Fehler und ich halte die High-Level-API für die "Datenmodellierung" einfach nicht für brauchbar. Der letzte Teil sollte jedoch keine Rolle spielen, da Sie einfach Ihr eigenes Datenmodell schreiben und Rohdateien lesen und schreiben können.

Ad 2: Das funktioniert total, aber jetzt haben Sie sich auf NextCloud/ownCloud beschränkt, während Sie sich mit der monströsen Komplexität von WebDAV auseinandersetzen müssen. Ich denke, ich kann für jeden sprechen, der jemals mit diesem Protokoll gearbeitet hat, wenn ich sage, dass sich die Nutzung von WebDAV nur um eines Standards willen nicht lohnt, wenn der Benutzer nicht davon profitiert.

Angesichts der Tatsache, dass Laverna bereits RemoteStorage-Unterstützung bietet, denke ich, dass es ein guter Weg ist, mehr Zeit in die Reparatur der rs.js-Clientbibliothek zu investieren, obwohl wir wahrscheinlich NextCloud-Unterstützung benötigen, damit jeder dieses Backend verwenden kann. Eine spezialisierte NextCloud-App ist IMO auch eine gute Option, die jedoch das Ziel, einen Standard zu haben, noch mehr verfehlt.

Hallo,
Bitte melden Sie sich an https://github.com/Laverna/laverna/issues/971#issuecomment -411423965, um den Stand dieses Projekts zu erläutern.

Schönen Tag/Nacht noch,
Danke schön,
Nissar