Laverna: Synchronisation avec un stockage non commercial

Créé le 17 mars 2014  ·  55Commentaires  ·  Source: Laverna/laverna

Projet sympa les gars !

Ce serait bien d'avoir une option de synchronisation avec un stockage non commercial, comme un serveur FTP/GIT auto-hébergé.

enhancement

Commentaire le plus utile

Ou Owncloud...

Tous les 55 commentaires

Ou Owncloud...

Regardez vole.cc. Ils ont un serveur personnalisé basé sur Go qui enregistre des éléments dans des fichiers. Vous pouvez probablement simplement vous y connecter pour un stockage local facile.

Oui brancher sur un owncloud sera parfait

La synchronisation avec OwnCloud serait intéressante.

Une option Bittorrent Sync serait également bien.

+1 pour owncloud

Comme @michielbdejong l'a écrit à propos de StackEdit , à l'intérieur, on pourrait trouver des approches intéressantes pour un connecteur de stockage de données multi-fournisseur généralisé.

De plus, remoteStorage est désormais également implémenté .

+1 pour owncloud !

+1

+1 Cozy.io, Owncloud, Bittorrent Sync. N'importe lequel d'entre eux serait génial !

Je pense que ce fil démontre la nécessité d'une méthode standardisée qui connecte Laverna aux fournisseurs de stockage. Chacun a son propre programme préféré pour l'hébergement des données personnelles. Il n'y a rien de mal à cela, mais maintenant que les développeurs ont fourni des moyens commerciaux viables (Dropbox) et non commerciaux (RemoteStorage), je préférerais qu'ils se concentrent sur l'expansion d'autres aspects du projet. Donner aux utilisateurs les outils pour se connecter par eux-mêmes libérerait du temps à long terme.

Je souhaite également la synchronisation Google Drive (ou même la synchronisation Google Keep)

+1 - Je suis également d'accord avec @andtheWings.

Mais pour l'instant, je pense que l'ajout de 2 services : GoogleDrive (principal, puisque la plupart des gens l'utilisent déjà) et OwnCloud (alternative non commerciale largement utilisée à Dropbox) couvrirait une très large base d'utilisateurs et ouvrirait les notes de Laverna à beaucoup plus de personnes.

Cela peut vraiment élargir la communauté.

Veuillez noter que remoteStorage apporte la synchronisation de Google Drive et Dropbox prête à l'emploi. Vérifiez sur 5apps.com .


_Edit:_ Bittorrent Sync dans le navigateur semble aventureux.

@almereyda Err, pourriez-vous être plus précis sur la façon dont puis-je stocker mes notes via remoteData sur Google Drive avec 5apps.com ?

@almereyda Si par "

Mais mon but est de diffuser l'utilisation de Laverna et de la rendre facilement adoptée par le grand public. Je pense que Google Drive est le chaînon manquant. La plupart des gens ont un compte Google et peuvent utiliser directement leur Google Drive plutôt que de redémarrer avec une autre inscription et configuration de service.

Étant donné que la plupart des gens ici préfèrent OwnCloud (y compris moi) et qu'il est ouvert/non commercial, je recommanderais certainement une option pour que celle-ci soit développée en premier sur Google Drive.

J'ai choisi d'utiliser Laverna, en espérant qu'il puisse évoluer en quelque chose capable de remplacer Evernone. J'utilise OwnCloud pour remplacer Dropbox, Google Drive ect. J'ai pris ces mesures pour ne plus avoir à dépendre de ces services et accepter leurs conditions. Je comprends que l'ajout de l'option de synchronisation avec des services tels que Dropbox augmenterait la popularité (et je l'encourage), mais pour moi personnellement, cela ne correspond pas.

@SandeepPinge

Hourra !

GDrive pour les masses / Owncloud pour les vrais !
à mon humble avis, Owncloud / GDrive constitue un excellent combo de logiciels libres / propriétaires.

J'exécute Laverna sur mon propre espace Web. Pourquoi je ne peux pas enregistrer les données (cryptées) directement sur le serveur Web ? Ou puis-je implémenter RemoteStorage sur mon serveur Web ? Je n'ai pas d'accès SSH !

Je pense que Laverna n'était pas considérée comme une application hébergée, mais fonctionne en local avec le stockage local des fichiers. Je préférerais également une solution hébergée, car elle facilite beaucoup la synchronisation entre les appareils.

Local?
Si je veux des notes locales, j'utilise notepad.exe.
;-)

Laverna a été conçu pour être non hébergé, c'est-à-dire pour que les données soient stockées localement sur le navigateur par défaut. Plus d'infos ici : https://unhosted.org/

"Aucun de nous ne peut accéder à vos données personnelles car nous utilisons IndexedDB et localStorage. En fait, toutes vos informations seront stockées uniquement côté client."
Cela signifie, autant dire que les données sont stockées localement (dans un dossier accessible par le navigateur). Mais on peut utiliser Dropbox (et, espérons-le, d'autres alternatives bientôt) pour synchroniser les notes.

Tout le monde, veuillez noter que remoteStorage est désormais disponible dans Cozy Cloud , vous pouvez donc facilement créer votre propre instance.

De plus, comme Laverna prend en charge remoteStorage, mais cela semble déjà être une ancienne spécification, des travaux sont également en cours pour l'intégrer dans ownCloud .

@michielbdejong @skddc Pourriez-vous jeter un coup d'œil rapide à Laverna et vérifier pourquoi il ne parvient pas à se synchroniser avec 5apps ? Cela fonctionnait, je crois avant la version 0.10. N'ont-ils tout simplement pas mis à jour le client ? Cela aurait-il un sens de submodule ?

Je ne connais pas Marionette ou le code source de cette application. Cependant, nous sommes toujours là pour aider et répondre à toutes les questions, à la fois générales et concrètes.

Quiconque maintient le support RS dans cette application (ou maintient l'application en général) : nous sommes impatients de vous accueillir dans #remotestorage sur Freenode ou de discuter de tout sur les forums ou GitHub.

J'ajouterais également Syncthing (https://syncthing.net/) et Seafile (http://seafile.com/en/home/).

1+ pour OwnCloud !

1+ OwnCloud

Owncloud serait génial.

Propre cloud +1

proprecloud +1

proprecloud +1
Je suis exactement dans la même situation que @Putdeksel
Être complètement en contrôle de vos notes en utilisant votre propre système de stockage serait incroyable.

Être complètement en contrôle de vos notes en utilisant votre propre système de stockage serait incroyable.

Oui, c'est incroyable et c'est déjà possible via le support RemoteStorage de Laverna. Vous n'êtes même pas lié à une implémentation de serveur unique, mais tout serveur utilisant le protocole RS peut stocker vos notes. ;)

@skddc Je n'ai pas examiné RemoteStorage pour être honnête. Mais malheureusement, d'après ce que je peux voir, il ne semble pas être pris en charge sur le serveur que j'ai de mon fournisseur. Espérons que ce sera le cas dans un avenir proche !

+1 propreCloud.

La synchronisation OwnCloud serait géniale.

+1 pour owncloud !

Puis-je suggérer quelque chose à tous les utilisateurs d'ownCloud ici :

Il serait _beaucoup_ plus facile pour les développeurs d'applications (pas seulement pour cette application) de prendre en charge ownCloud, si ownCloud prenait en charge un protocole ouvert pour le stockage de données par utilisateur. Cette application prend déjà en charge remoteStorage, donc si ownCloud prenait en charge remoteStorage, au lieu que les développeurs aient à ajouter une prise en charge spéciale d'ownCloud à leurs applications, alors toutes les applications compatibles avec remoteStorage fonctionneraient également automatiquement avec ownCloud agissant comme serveur de stockage à distance.

Par conséquent, je pense que ce serait formidable si vous demandiez/votiez pour, ou contribuiez au support RS à ownCloud lui-même !

Suite à cette conversation depuis quelques années déjà, je dois appuyer
Dernière remarque de @skddc .

Le 25 juillet 2016 à 14h22, Sebastian Kippe [email protected] a écrit :

Puis-je suggérer quelque chose à tous les utilisateurs d'ownCloud ici :

Il serait _beaucoup_ plus facile pour les développeurs d'applications (pas seulement de cette application) de
prend en charge ownCloud, si ownCloud prend en charge un protocole ouvert pour chaque utilisateur
stockage de données. Cette application prend déjà en charge remoteStorage, donc si ownCloud était
pour prendre en charge remoteStorage, au lieu que les développeurs aient à ajouter des
prise en charge d'ownCloud pour leurs applications, alors toutes les applications compatibles avec remoteStorage seraient
fonctionnent également automatiquement avec ownCloud agissant comme serveur de stockage à distance.

Par conséquent, je pense que ce serait formidable si vous demandiez/votiez pour, ou contribuiez RS
prise en charge d'ownCloud lui-même !

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/Laverna/laverna/issues/6#issuecomment -234938265, ou muet
le fil
https://github.com/notifications/unsubscribe-auth/ABka_MqpAc9pic432ehmtZ58HBUTh2Iyks5qZKqOgaJpZM4BqQ_m
.

Je +1 ce numéro !

Hmm serait-il difficile d'implémenter webDAV car cela pourrait être considéré comme un standard ouvert qui permettra à laverna d'être connecté à des dizaines de fournisseurs de stockage différents ?

Pourquoi ne pas stocker les données dans un répertoire local spécifié et les utilisateurs peuvent synchroniser leurs données dans le cloud via des clients de synchronisation tels que Seafile ou les clients ownCloud Desktop ?

Pourquoi ne pas stocker les données dans un répertoire local spécifié et les utilisateurs peuvent synchroniser leurs données dans le cloud via des clients de synchronisation tels que Seafile ou les clients ownCloud Desktop ?

Cela n'est possible que dans une version packagée potentielle de l'application, mais pas sur le Web. C'est aussi ce que résout remoteStorage et pourquoi il est utilisé dans Laverna.

Quelqu'un ici a-t-il ouvert un problème d'ownCloud sur l'intégration de remoteStorage jusqu'à présent ? Je ne peux que souligner à quel point ce serait formidable et que Laverna prendrait alors automatiquement en charge ownCloud.

Cela n'est possible que dans une version packagée potentielle de l'application, mais pas sur le Web. C'est aussi ce que résout remoteStorage et pourquoi il est utilisé dans Laverna.

En fait, je n'ai jamais réussi à avoir une synchronisation remoteStorage entièrement fonctionnelle. J'ai essayé plusieurs fois, et c'est plutôt difficile de traiter avec tout le monde à chaque fois. Je ne suis pas très à l'aise avec les données IndexedDB...

Je suis plutôt familier avec les synchronisations DAV. @wwebfor m'a dit qu'il existe un autre moyen de synchroniser dans le four, pensa-t-il.

En fait, je n'ai jamais réussi à avoir une synchronisation remoteStorage entièrement fonctionnelle. J'ai essayé plusieurs fois, et c'est plutôt difficile de traiter avec tout le monde à chaque fois.

Êtes-vous en train de dire que cela a échoué après que la synchronisation ait été corrigée il y a quelque temps et que vous ayez ouvert un problème à ce sujet, qui n'a pas abouti ?

Je n'ai pas vu de tels problèmes ou demandes, mais je serais heureux de vous aider! Je ne sais pas ce que signifie "difficile de traiter avec tout le monde à chaque fois".

Je ne suis pas très à l'aise avec les données IndexedDB

Eh bien, c'est fondamentalement la seule base de données disponible localement dans les navigateurs modernes (à l'exception de localStorage bien sûr), donc il n'y a pas vraiment d'options pour utiliser autre chose.

Êtes-vous en train de dire que cela a échoué après que la synchronisation ait été corrigée il y a quelque temps et que vous ayez ouvert un problème à ce sujet, qui n'a pas abouti ?

Non, j'ai demandé sur Gitter, et je suis arrivé à la conclusion que je devais nettoyer toutes mes données sur chaque navigateur que j'ai utilisé car il semble que cela fonctionne correctement sur un navigateur propre (où Laverna n'a jamais été utilisé).

Je ne sais pas ce que signifie "difficile de traiter avec tout le monde à chaque fois".

Chaque navigateur (ou client de bureau) que j'utilise, chaque fois que j'utilise l'un d'entre eux.

Eh bien, c'est fondamentalement la seule base de données disponible localement dans les navigateurs modernes (à l'exception de localStorage bien sûr), donc il n'y a pas vraiment d'options pour utiliser autre chose.

Oui, oui, je comprends. Mais je voulais dire que je ne suis pas habitué à cette façon de synchroniser les données.

Cela ressemble à un problème de mise à niveau pour moi. Alors, quand tu écris...

En fait, je n'ai jamais réussi à avoir une synchronisation remoteStorage entièrement fonctionnelle

... ça veut dire que ça ne marche toujours pas ? Si c'est le cas, je serais toujours heureux de vous aider.

+1 pour webDAV, bien plus standard qu'une solution "Owncloud only". Restons ouverts les gars.

Au lieu d'intégrer un tas de nouvelles solutions hipster absurdes comme remoteStorage, pourquoi ne pas utiliser webDav qui a fait ses preuves ? Je veux dire à quoi ça sert ? Pourquoi forcez-vous les utilisateurs à se plier à votre volonté si la norme de l'industrie est de facto autre chose ?

Dire oui, rs soutient cela et cela est peu utile à la plupart des gens. Mais je ne veux pas utiliser encore un autre protocole dont je ne me soucie pas. Vous prenez en charge Dropbox commerciale, mais POSSÉDER les notes signifie que je ne veux pas les enregistrer sur un serveur tiers. Vous ne voulez tout simplement pas comprendre que votre logiciel ne survivra que si les gens veulent l'utiliser en raison de sa convivialité et de sa flexibilité. Au lieu de cela, vous visez à les forcer à faire quelque chose qu'ils ne veulent pas faire. Ce sont tous des développeurs et des férus de technologie, vous ne comprenez tout simplement pas ce simple fait.

@technodrome Je ne parle pas pour les développeurs de Laverna, mais en tant que développeur remoteStorage.js. Ce n'est peut-être pas clair, qu'essayer d'aider les gens ici (je n'ai jamais rien essayé d'autre, si vous lisez attentivement l'histoire) n'est pas la même chose que de dire aux gens de s'en aller, parce que leurs opinions ne sont pas valides ou entendues par quelqu'un d'autre. C'est certainement le bon endroit pour les exprimer pour autant que je puisse voir, et je ne sais pas pourquoi votre premier commentaire dans ce fil est si hostile. Soyons tous gentils les uns envers les autres, car il s'agit d'un travail bénévole non rémunéré pour nous tous !

Au lieu de cela, vous visez à les forcer à faire quelque chose qu'ils ne veulent pas faire

Je ne vois pas en quoi fournir un logiciel open source, gratuitement, est d'armer quelqu'un. Si ce sont tous des développeurs et des experts en technologie, quelqu'un peut sûrement contribuer au support WebDAV, si cela a du sens ?

Voyons donc objectivement la viabilité de WebDAV. Voici une liste (probablement incomplète) des problèmes auxquels je peux penser, qui devraient être résolus pour que WebDAV soit intégré. (Ce sont essentiellement les raisons mêmes pour lesquelles le protocole remoteStorage a été créé en premier lieu. En fait, RS utilisait WebDAV au tout début, et les auteurs ont décidé de le supprimer en faveur d'une API REST plus simple, basée sur le monde réel tests et expérience avec cela):

1. SCRO

Le fonctionnement des navigateurs est qu'une application non hébergée comme Laverna se connecte directement au serveur à partir de JavaScript. Cela comporte la restriction que le serveur doit offrir des en-têtes de ressources d'origine croisée pour toutes les demandes et prendre en charge les demandes de pré-vol OPTIONS pour les verbes HTTP qui peuvent manipuler des données, comme par exemple POST, PUT, DELETE. La plupart des serveurs WebDAV ne le prennent pas en charge. Ainsi, de nombreux serveurs WebDAV seraient incompatibles avec Laverna prêt à l'emploi.

Problème : même si l'on ne se soucie pas de l'incompatibilité de ces serveurs, comment une application détecterait-elle s'il y a un support ? Cela est en fait rendu beaucoup plus difficile par les navigateurs qui ne donnent intentionnellement pas de détails de code JS sur les raisons de l'échec de la connexion, il faudrait donc une sorte de mécanisme de découverte. En outre, il doit être expliqué à l'utilisateur quelle pourrait être exactement la cause et qu'il devra peut-être changer de serveur pour utiliser l'application.

Solution en RS : le protocole nécessite CORS prêt à l'emploi. De plus, la découverte est gérée via Webfinger, où l'adresse de l'utilisateur peut renvoyer toutes les informations de configuration, mais aussi où des capacités supplémentaires du serveur peuvent être annoncées.

Solution pour WebDAV/Laverna simple : des idées ?

2. Autorisations / Autorisation

Les autorisations doivent être gérées côté serveur et par compte dans WebDAV, car rien de tel n'est intégré au protocole. L'autorisation d'accès à certains dossiers n'existe pas.

Solution dans RS : OAuth 2.0, afin que les développeurs d'applications puissent décider à quelle partie du stockage ils ont besoin d'accéder, et les utilisateurs peuvent facilement voir de quelle partie il s'agit et décider d'accorder l'accès dans une simple boîte de dialogue.

Solution pour WebDAV/Laverna simple : C'est fondamentalement impossible, mais il serait bien sûr possible de simplement ignorer cette fonctionnalité et de donner volontairement à Laverna l'accès à toutes ses données. Pas élégant, mais certainement pas un obstacle pour la mise en œuvre.

3. Assistance hors ligne/mobile

Ce n'est pas particulièrement un problème de WebDAV ou entièrement résolu dans la spécification RS. Mais pour une application Web compatible avec les mobiles, c'est néanmoins un facteur important. Les connexions de bureau et mobiles tombent régulièrement, et on ne voudrait pas que leurs notes ne soient pas enregistrées à cause de cela. Une sorte de stockage hors ligne doit donc être utilisé et synchronisé intelligemment avec le serveur distant (et bien sûr sans ré-authentification après chaque chute si vous souhaitez créer une bonne expérience utilisateur).

Ici, nous avons deux problèmes:

Problème 1 : les serveurs doivent prendre en charge les Etags, donc on est capable de créer un mécanisme de synchronisation en premier lieu

Solution dans RS : Ceci est en partie résolu dans le protocole en exigeant des ETags à la fois sur les ressources du répertoire et leurs listes d'éléments, ainsi que sur les documents individuels eux-mêmes. Sur cette base, on peut créer des mécanismes de synchronisation en utilisant des en-têtes HTTP comme par exemple If-None-Match et des réponses comme par exemple vide 304 s pour demander des choses qui n'ont pas changé et 412 pour refuser de écraser quelque chose qui a changé sur un autre appareil à un autre moment.

Solution pour WebDAV/Laverna : Malheureusement, la prise en charge d'Etag n'est qu'un DEVRAIT dans la spécification WebDAV, donc de nombreux serveurs ne la prennent pas en charge, et certains demandent même explicitement à leurs utilisateurs de désactiver la prise en charge, même s'ils l'ont, car elle est implémentée de manière non performante. (Ce n'est en fait pas un problème facile pour un développeur de serveur, je peux certainement en témoigner). Mais similaire à CORS, c'est possible, donc la solution ici serait encore une fois de découvrir des fonctionnalités et de guider les utilisateurs pour configurer leur serveur ou leur dire qu'ils doivent passer à un autre serveur. Heureusement, c'est beaucoup plus facile qu'avec CORS, car on peut le détecter à partir de JS en inspectant les en-têtes de réponse.

Problème 2 : écrivez un mécanisme de synchronisation réel ou utilisez une bibliothèque qui en fournit un

Solution dans RS : très tôt, l'un des auteurs de spécifications a commencé à créer une bibliothèque cliente de référence pour résoudre ce problème pour les personnes souhaitant intégrer RS ​​dans leurs applications. Il est toujours en cours de maintenance et de développement et a été testé au combat sur des centaines de milliers de connexions, d'appareils, de systèmes d'exploitation, de navigateurs différents, à Cordoue, etc. Il est également utilisé à Laverna. Le premier commit remonte à novembre 2010, donc ce n'est certainement pas une "nouvelle solution hipster". S'il y a des bogues avec, il y a des gens qui sont heureux de vous aider, et tout commentaire a été et est toujours apprécié (d'où mes réponses proactives dans ce fil).

Solution pour WebDAV/Laverna simple : Une solution possible serait une bibliothèque personnalisée roulée à la main. L'effort pour créer, réparer et maintenir un tel code éclipserait certainement les autres problèmes que j'ai énumérés, et pourtant il est bien sûr tout à fait possible de le faire. Le principal défi que je suppose, mis à part littéralement mille autres choses à mettre en œuvre, est probablement le comportement variable des serveurs WebDAV à la fin, en particulier. leur implémentation Etag. Cependant, si vous connaissez une telle bibliothèque (je n'en connais aucune, et je n'en ai pas trouvé non plus, lorsque j'ai vérifié à nouveau tout à l'heure), il deviendrait très possible de résoudre les autres problèmes en suspens d'une manière ou d'une autre et de fournir WebDAV à utilisateurs techniques.


Veuillez excuser et signaler toute erreur ou fait erroné contenu dans cette liste. En gros, j'ai tout écrit du haut de ma tête. Je vais bientôt transférer cela sur le wiki RS et demander à certaines personnes de revoir/modifier ce que j'ai écrit, car je pense que c'est en fait une explication plutôt utile des différences entre WebDAV et RS, et comment RS résout les choses que WebDAV n'a pas, en ce qui concerne les applications Web côté client qui s'exécutent entièrement dans le navigateur (ce qui est compréhensible, car les capacités de la plate-forme Web n'existaient pas vraiment à l'époque et le concept d'applications Web hors ligne n'était pas un chose).

@technodrome Si vous souhaitez faire progresser votre objectif d'obtenir le support WebDAV, alors indiquer des solutions potentielles à l'un de ces problèmes (ou des faits qui les annulent complètement) serait probablement très utile.

Désolé, mais si vous ne pouvez pas comprendre le point de vue des utilisateurs de bon sens parce que vous pensez que cela blesse vos sentiments ou vos opinions, alors le problème est avec vous. Le logiciel destiné aux personnes est par définition utilisé par plus d'une personne - pas seulement par vous. En tant que tel, tout le monde devrait être invité à donner son avis car le brainstorming et les idées sont ce qui fait avancer les projets. Et à en juger par les personnes qui attribuent +1 à webDav ou à un autre support de protocole standardisé, ce n'est pas seulement moi.

Vous essayez de déformer ce que j'ai dit et de prendre les choses personnellement même si elles étaient censées être une opinion personnelle à un niveau général. Mais au fait - si un développeur n'offre aucune méthode standardisée de sauvegarde des données utilisateur, alors oui - il/elle arme fortement l'utilisateur pour qu'il utilise la préférence du développeur.

Les utilisateurs férus de technologie n'égalent pas les programmeurs. Ne sautez pas aux conclusions simplement parce que cela correspond à votre rhétorique.

De plus, j'ai clairement dit que j'appréciais le travail et les efforts et je le fais vraiment. Cela ne signifie tout simplement pas que je serai aveuglément d'accord avec tout simplement parce que vous l'avez dit. C'est mon droit comme c'est le vôtre et il y a des millions de façons de résoudre ce problème. Bien sûr, vous poussez votre produit, mais soyons un peu démocrates ici et offrons une liberté de choix qui convient à plus de gens, pas seulement à vous.

Bien que vous ayez énuméré une multitude de raisons pour lesquelles cela ne peut pas fonctionner et pourquoi votre solution RS est le remède à tous les maux, je suis sûr qu'un point de terminaison intermédiaire (application Go ?) permet une multitude de possibilités d'intégrer à peu près n'importe quel protocole que vous voulez. Cela apporte sûrement moins de maux de tête que de maintenir toute une pile de technologies, qui peuvent ou non être oubliées et obsolètes dans deux ans.

De plus, mon commentaire n'avait pas pour but de prouver que quelqu'un avait tort, juste pour dire qu'il existe une certaine norme de l'industrie et qu'il y a une raison pour laquelle les choses deviennent une telle norme. Si vous ne pouvez pas comprendre cela, je crains qu'il n'y ait aucune argumentation qui puisse vous convaincre d'une autre vérité que la vôtre.

Eh bien, j'ai lu de bons arguments des deux côtés. Finalement, posséder mon stockage était une exigence pour moi, et je suis passé à turtl car le stockage (crypté) sur le serveur fait partie du cœur du projet.
Comme mentionné précédemment, si un produit ne répond pas à tous vos besoins, et dans ce cas il semble y avoir des raisons (avec lesquelles bien sûr on pourrait toujours discuter), alors cherchez quelque chose de plus proche de vos besoins et exigences.
Je suis sûr que beaucoup de gens acceptent d'héberger leur fichier sur Dropbox. Pas besoin de s'énerver, surtout sur un produit open source. Je comprends et partage la frustration cependant, mais l'open source a de nombreux plans d'affaires, et parfois ils ne répondent pas à nos exigences. Faut juste s'en occuper.

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

Désolé, mais si vous ne pouvez pas comprendre le point de vue de l'utilisateur de bon sens
parce que vous pensez que cela blesse vos sentiments ou vos opinions, alors le problème
est avec vous. Le logiciel destiné aux personnes est par définition utilisé par
plus d'une personne - pas seulement vous. En tant que tel, tout le monde devrait être
invité à donner son avis parce que le brainstorming et les idées sont ce
fait avancer les projets. Et à en juger par les personnes qui ont attribué +1 pour
webDav ou autre support de protocole standardisé, ce n'est pas seulement moi.

Tu essaies de déformer ce que j'ai dit et de prendre les choses personnellement
bien qu'ils aient été conçus comme une opinion personnelle à un niveau général. Mais à
le point - si un développeur n'offre aucune méthode standardisée de
sauvegarde les données de l'utilisateur, alors oui - il/elle arme fortement l'utilisateur pour
utiliser la préférence du développeur.

Les utilisateurs férus de technologie n'égalent pas les programmeurs. Ne sautez pas aux conclusions
juste parce que cela correspond à votre rhétorique.

De plus, j'ai clairement dit que j'appréciais le travail et les efforts et je le fais vraiment.
Cela ne veut pas dire que je serai aveuglément d'accord avec tout simplement parce que
tu l'as dit. C'est mon droit comme c'est le tien et il y a des millions de façons
comment procéder pour résoudre ce problème. Bien sûr, vous poussez votre
produit mais soyons un peu démocrates ici et offrons une liberté de
choix qui convient à plus de gens, pas seulement à vous.

Bien que vous ayez énuméré une multitude de raisons pour lesquelles cela ne peut pas fonctionner et pourquoi votre
La solution RS est le remède à tous les maux, je suis sûr qu'un intermédiaire
le point de terminaison (Go app ?) s'exécutant en tant que démon local (client, serveur) pourrait
s'occuper de l'autorisation et permettre une multitude de possibilités pour
intégrer à peu près n'importe quel protocole que vous voulez. ça rapporte sûrement moins
mal de tête que de maintenir toute une pile de technologies, ce qui peut ou peut
ne pas être oublié et obsolète dans deux ans.

De plus, mon commentaire n'avait pas pour but de prouver que quelqu'un avait tort, juste pour dire
il y a une certaine norme de l'industrie et il y a une raison pour laquelle les choses
devenir une telle norme. Si vous ne pouvez pas comprendre cela, j'ai peur
il n'y a aucune argumentation qui pourrait vous convaincre d'une autre vérité
que la vôtre.

--
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/Laverna/laverna/issues/6#issuecomment -282279742

--
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

En tant que tel, tout le monde devrait être invité à donner son avis car le brainstorming et les idées sont ce qui fait avancer les projets. Et à en juger par les personnes qui attribuent +1 à webDav ou à un autre support de protocole standardisé, ce n'est pas seulement moi.

Oui! J'ai dit exactement cela, puis j'ai passé du temps et des efforts à souligner ce qui, à mon avis, devrait être résolu afin de réaliser votre souhait. Je n'ai rien déformé pour "corriger mon agenda", et je vous invite activement, ainsi que toute autre personne, à signaler toute erreur contenue dans mon analyse objective et je vous ai également invité à faire progresser la mise en œuvre de votre propre préférence/idée.

Malheureusement, il n'est pas facile de trouver des arguments substantiels ou de nouveaux faits parmi les accusations dans votre commentaire de suivi. Mais un paragraphe contient au moins une idée :

Je suis sûr qu'un point de terminaison intermédiaire (application Go ?) s'exécutant en tant que démon local (client, serveur) pourrait s'occuper de l'autorisation et permettre une multitude de possibilités d'intégrer à peu près n'importe quel protocole de votre choix

Alors oui, ce serait bien sûr possible en théorie. Le problème, c'est que cela entre totalement en conflit avec vos propres opinions et arguments dans le même paragraphe :

Cela apporte sûrement moins de maux de tête que de maintenir toute une pile de technologies, qui peuvent ou non être oubliées et obsolètes dans deux ans.

Votre idée signifierait exactement cela : créer, tester et maintenir une toute nouvelle pile de technologies (« client, serveur ») afin que l'application Web puisse stocker des données à distance et les synchroniser sur tous les appareils. Outre le problème d'inventer et de maintenir cette toute nouvelle pile, il serait également assez difficile d'exécuter ce programme local sur tous vos appareils, surtout les mobiles.

De plus, mon commentaire n'avait pas pour but de prouver que quelqu'un avait tort, juste pour dire qu'il existe une certaine norme de l'industrie et qu'il y a une raison pour laquelle les choses deviennent une telle norme.

Je suis tout à fait d'accord avec ça ! Et j'ai longuement expliqué pourquoi WebDAV n'est en effet pas devenu ce standard pour les applications Web côté client, et pourquoi le protocole RS a été créé --initialement avec WebDAV en tant qu'API même-- comme une nouvelle norme pour rendre par utilisateur, auto-hébergé stockage possible pour ce type précis d'applications.

Il s'agit en fait d'un protocole assez simple et à l'opposé d'une "pile technologique". Au cas où vous n'auriez pas vu l'explication rapide de ses pièces, vous pouvez la trouver sur ce site . -- De plus, concernant "webDav ou autre support de protocole standardisé", c'est exactement ce que RS est censé être .

Maintenant, vous pouvez bien sûr penser négativement que WebDAV n'est pas une solution trop viable pour les applications Web côté client, mais cela ne change en rien les faits, ni ne fait de moi un connard égoïste pour les avoir signalés. S'il vous plaît, plaît , discutons de cela de manière rationnelle, et gardons les accusations personnelles en dehors de cela. J'essaie seulement d'aider, et il n'y a absolument aucun besoin de négativité. Encore une fois : j'essaie en fait de vous aider à atteindre votre objectif, et je ne prétends certainement pas que RS soit une solution exclusive du tout. Si quelqu'un peut proposer une autre solution, qui atteint les mêmes objectifs, alors je suis la dernière personne à m'y opposer en fonction de ses préférences personnelles ou de son idéologie.

Laverna, en tant qu'application Web, ne peut prendre en charge que HTTP en tant que protocole de transfert et nécessite CORS pour que tout fonctionne. Pourtant, pour une raison quelconque, les gens proposent des choses comme BitTorrent Sync ou WebDAV, dont l'une ne fonctionne pas sur HTTP et dont aucune n'a CORS dans sa spécification. En fait, le premier n'a même pas de spécification, c'est un protocole propriétaire. @technodrome va même jusqu'à appeler l'utilisation de WebDAV "perspective utilisateur de bon sens", bien que, encore une fois, l'utilisation de WebDAV à partir d'une application Javascript dans le navigateur ne fonctionne tout simplement pas dans le cas général et n'a donc aucun sens, quelle que soit la perspective . Le discours sur l'utilisation d'un proxy intermédiaire pour ajouter des en-têtes CORS ne correspond pas non plus à mon idée d'une bonne UX.

Je pense que cela montre vraiment que cette discussion est principalement dominée par des personnes souhaitant une "liberté générale du logiciel" et jetant les noms de certains protocoles établis, et non par des personnes qui ont réellement examiné sérieusement l'une de ces options d'un point de vue technique et déterminé si elles sont le bon outil pour le travail. Encore une fois , je voudrais appeler @technodrome, qui , en plus d' une crise de colère jette parce qu'il (compréhensible) perçoit @skddc « de plaidoyer pour RemoteStorage en shilling poussant son propre ordre du @skddc est le premier dans ce fil argumenter convenablement le protocole qu'il propose.

Peut-être devrions-nous simplement admettre que même après les trois ans où cette question a été ouverte, il n'y a tout simplement pas de norme pour cela. Ce qui nous laisse trois options :

  1. Pariez sur remoteStorage, pas encore standard
  2. Utilisez quand même WebDAV, mais nécessitez des en-têtes CORS. En fait, cela signifie uniquement la prise en charge de NextCloud et d'ownCloud.
  3. Écrire un plugin NextCloud personnalisé, avec une API personnalisée

Annonce 1 : remoteStorage en tant que protocole est assez bon, mais je ne pense pas que la bibliothèque cliente soit encore là. En fait, la dernière expérience que j'ai eue avec remoteStorage.js (la bibliothèque cliente) n'était pas bonne. Tout a en quelque sorte fonctionné, mais il y avait encore des bogues mineurs partout et je ne considère tout simplement pas que l'API de « modélisation des données » de haut niveau soit utilisable. La dernière partie ne devrait cependant pas avoir d'importance, étant donné que vous pouvez simplement écrire votre propre modèle de données et lire et écrire des fichiers bruts.

Ad 2: Cela fonctionne totalement, mais maintenant vous vous êtes limité à NextCloud/ownCloud tout en devant faire face à la complexité monstrueuse de WebDAV. Je pense que je peux parler au nom de tous ceux qui ont déjà travaillé avec ce protocole lorsque je dis que l'utilisation de WebDAV juste pour utiliser une norme ne vaut pas la peine si l'utilisateur n'en profite pas.


Étant donné que Laverna prend déjà en charge remoteStorage, je suppose qu'investir plus de temps dans la réparation de la bibliothèque cliente rs.js est un bon moyen d'aller de l'avant, bien que nous ayons probablement besoin de la prise en charge de NextCloud pour que quiconque puisse utiliser ce backend. Une application NextCloud spécialisée est également une bonne option IMO, bien que cela manque encore plus l'objectif d'avoir une norme.

Bonjour,
Veuillez vous rapporter à https://github.com/Laverna/laverna/issues/971#issuecomment -411423965 qui explique l'état de ce projet.

Bonne journée/nuit,
À votre santé,
Nissar

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

magowiz picture magowiz  ·  7Commentaires

hgaronfolo picture hgaronfolo  ·  5Commentaires

JerJohn15 picture JerJohn15  ·  4Commentaires

wwebfor picture wwebfor  ·  4Commentaires

Issam2204 picture Issam2204  ·  8Commentaires