Laverna: Sincronizar con almacenamiento no comercial

O Owncloud ...

Mira vole.cc. Tienen un servidor personalizado basado en Go que guarda cosas en archivos. Probablemente podría simplemente enchufarlo para un fácil almacenamiento local.

Sí, conectarlo a una propia nube será perfecto

Sincronizar con OwnCloud sería interesante.

Una opción de Bittorrent Sync también estaría bien.

+1 para owncloud

Como @michielbdejong escribió sobre StackEdit , en su interior se pueden encontrar enfoques interesantes para un conector de almacenamiento de datos de múltiples proveedores generalizado.

Además, ahora también se implementa remoteStorage .

+1 para owncloud!

+1

+1 Cozy.io, Owncloud, Bittorrent Sync. ¡Cualquiera de esos sería genial!

Creo que este hilo demuestra la necesidad de un método estandarizado que conecte a Laverna con los proveedores de almacenamiento. Todo el mundo tiene su propio programa preferido para alojar datos personales. No hay nada de malo en eso, pero ahora que los desarrolladores han proporcionado medios comerciales (Dropbox) y no comerciales (RemoteStorage) viables para hacerlo, preferiría que se centraran en expandir otros aspectos del proyecto. Darles a los usuarios las herramientas para conectarse por sí mismos liberaría tiempo a largo plazo.

También me gustaría sincronizar Google Drive (o incluso sincronizar Google Keep)

+1 - También estoy de acuerdo con @andtheWings.

Pero por ahora creo que agregar 2 servicios: GoogleDrive (principal, ya que la mayoría de la gente ya lo está usando) y OwnCloud (alternativa no comercial de Dropbox ampliamente utilizada) cubriría una base de usuarios muy grande y abriría las notas de Laverna a muchas más personas.

Esto realmente puede expandir la comunidad.

Tenga en cuenta que remoteStorage trae la sincronización de Google Drive y Dropbox lista para usar. Consulte en 5apps.com .

_Editar: _ Bittorrent Sync en el navegador suena aventurero.

@almereyda Err, ¿podría ser más específico cómo puedo almacenar mis notas a través de remoteData en Google Drive con 5apps.com?

@almereyda Si por 'sincronización inmediata' te refieres a tu propio control, OwnCloud también.

Pero mi punto es difundir el uso de Laverna y hacer que el público en general lo adopte fácilmente. Creo que Google Drive es el enlace que falta allí. La mayoría de las personas tienen una cuenta de Google y pueden usar directamente su Google Drive en lugar de reiniciar con otro registro y configuración de servicio.

Dado que la mayoría de las personas aquí prefieren OwnCloud (incluyéndome a mí) y es abierto / no comercial, definitivamente recomendaría una opción para que se desarrolle primero en Google Drive.

Elegí usar Laverna, con la esperanza de que pudiera convertirse en algo capaz de reemplazar a Evernone. Estoy usando OwnCloud para reemplazar Dropbox, Google Drive, etc. Tomé estos pasos para no tener que depender más de esos servicios y estar de acuerdo con sus términos. Entiendo que agregar la opción de sincronizar con servicios como Dropbox aumentaría la popularidad (y lo aliento), pero para mí personalmente no encaja.

@SandeepPinge

¡Hurra!

GDrive para las masas / Owncloud para las reales!
En mi humilde opinión, Owncloud / GDrive es una excelente combinación de software gratuito / propietario.

Estoy ejecutando Laverna en mi propio espacio web. ¿Por qué no puedo guardar los datos (cifrados) directamente en el servidor web? ¿O puedo implementar RemoteStorage en mi servidor web? ¡No tengo acceso SSH!

Creo que no se pensó que Laverna fuera una aplicación alojada, sino que se ejecuta de forma local con el almacenamiento local de los archivos. También preferiría una solución alojada, ya que facilita mucho la sincronización entre dispositivos.

¿Local?
Si quiero notas locales, uso notepad.exe.
;-)

Laverna se diseñó para no estar alojado, es decir, para que los datos se almacenen localmente en el navegador de forma predeterminada. Más información aquí: https://unhosted.org/

"Ninguno de nosotros puede acceder a sus datos personales porque estamos usando IndexedDB y localStorage. De hecho, toda su información se almacenará sólo en el lado del cliente".
Esto significa, afaik que los datos se almacenan localmente (en una carpeta a la que puede acceder el navegador). Pero se puede usar Dropbox (y con suerte otras alternativas pronto) para sincronizar las notas.

Todos, tenga en cuenta que remoteStorage ahora está disponible en Cozy Cloud , por lo que puede girar fácilmente su propia instancia.

Además, como Laverna es compatible con remoteStorage, pero parece una especificación antigua, también se está trabajando para integrarlo en ownCloud .

@michielbdejong @skddc ¿Podrías echar un vistazo rápido a Laverna e inspeccionar por qué no se sincroniza con 5apps? Solía ​​funcionar, creo que antes de la versión 0.10. ¿Simplemente no actualizaron el cliente? ¿Tendría sentido submodule ?

No estoy familiarizado con Marionette o el código fuente de esta aplicación. Sin embargo, siempre estamos aquí para ayudar y responder a todas las preguntas, tanto generales como concretas.

Quien mantiene el soporte de RS en esta aplicación (o mantiene la aplicación en general): estamos ansiosos por darle la bienvenida en #remotestorage en Freenode o charlar sobre cualquier cosa en los foros o GitHub.

También agregaría Syncthing (https://syncthing.net/) y Seafile (http://seafile.com/en/home/).

1+ para OwnCloud!

1+ OwnCloud

Owncloud sería genial.

Owncloud +1

owncloud +1

owncloud +1
Estoy en la misma situación que @Putdeksel
Sería increíble tener el control total de sus notas utilizando su propio sistema de almacenamiento.

Sería increíble tener el control total de sus notas utilizando su propio sistema de almacenamiento.

Sí, es increíble y ya es posible a través del soporte RemoteStorage de Laverna. Ni siquiera está atado a una implementación de servidor único, pero cualquier servidor que utilice el protocolo RS puede almacenar sus notas. ;)

@skddc Para ser honesto, no he investigado RemoteStorage. Pero, lamentablemente, por lo que puedo ver, no parece ser compatible con el servidor que tengo de mi proveedor. ¡Ojalá lo sea en un futuro próximo!

+1 ownCloud.

La sincronización OwnCloud sería genial.

+1 para owncloud!

Puedo sugerir algo a todos los usuarios de ownCloud aquí:

Sería _mucho_ más fácil para los desarrolladores de aplicaciones (no solo de esta aplicación) admitir ownCloud, si ownCloud fuera compatible con un protocolo abierto para el almacenamiento de datos por usuario. Esta aplicación ya es compatible con remoteStorage, por lo que si ownCloud fuera compatible con remoteStorage, en lugar de que los desarrolladores tuvieran que agregar soporte especial ownCloud a sus aplicaciones, todas las aplicaciones habilitadas para remoteStorage también funcionarían automáticamente con ownCloud actuando como servidor de almacenamiento remoto.

Por lo tanto, creo que sería genial si pidieras / votaras o contribuyeses con el soporte de RS a ownCloud.

Después de esta conversación desde hace algunos años, tengo que segundo
El último comentario de @skddc .

El 25 de julio de 2016 a las 14:22, Sebastian Kippe [email protected] escribió:

Puedo sugerir algo a todos los usuarios de ownCloud aquí:

Sería mucho más fácil para los desarrolladores de aplicaciones (no solo para esta aplicación)
admite ownCloud, si ownCloud fuera compatible con un protocolo abierto para cada usuario
almacenamiento de datos. Esta aplicación ya es compatible con remoteStorage, por lo que si ownCloud fuera
para admitir almacenamiento remoto, en lugar de que los desarrolladores tengan que agregar
ownCloud para sus aplicaciones, entonces todas las aplicaciones habilitadas para RemoteStorage
También funciona automáticamente con ownCloud actuando como servidor de almacenamiento remoto.

Por lo tanto, creo que sería genial si pidieras / votaras o contribuyeses con RS
soporte para ownCloud mismo!

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/Laverna/laverna/issues/6#issuecomment -234938265, o silenciar
la amenaza
https://github.com/notifications/unsubscribe-auth/ABka_MqpAc9pic432ehmtZ58HBUTh2Iyks5qZKqOgaJpZM4BqQ_m
.

¡Yo +1 este problema!

Mmmm, ¿sería difícil implementar webDAV ya que esto podría verse como un estándar abierto que permitirá que laverna se conecte a docenas de proveedores de almacenamiento diferentes?

¿Por qué no almacenar los datos en un directorio local específico y las personas pueden sincronizar sus datos en la nube a través de clientes de sincronización como Seafile o clientes ownCloud Desktop?

¿Por qué no almacenar los datos en un directorio local específico y las personas pueden sincronizar sus datos en la nube a través de clientes de sincronización como Seafile o clientes ownCloud Desktop?

Eso solo es posible en una posible versión empaquetada de la aplicación, pero no en la Web. También es lo que resuelve remoteStorage y por qué se usa en Laverna.

¿Alguien aquí abrió un problema de ownCloud sobre la integración de RemoteStorage hasta ahora? Solo puedo enfatizar lo genial que sería y que Laverna automáticamente admitiría ownCloud.

Eso solo es posible en una posible versión empaquetada de la aplicación, pero no en la Web. También es lo que resuelve remoteStorage y por qué se usa en Laverna.

De hecho, nunca logré tener una sincronización de almacenamiento remoto completamente funcional. Lo intenté muchas veces, y es bastante difícil tratar con todos cada vez. No me siento tan cómodo con los datos de IndexedDB ...

Estoy bastante familiarizado con las sincronizaciones de DAV. @wwebfor me dijo que hay otra forma de sincronizar en el horno, pensó.

De hecho, nunca logré tener una sincronización de almacenamiento remoto completamente funcional. Lo intenté muchas veces, y es bastante difícil tratar con todos cada vez.

¿Está diciendo que falló después de que la sincronización se solucionó hace un tiempo y abrió un problema al respecto que no llegó a una conclusión?

No he visto ningún problema o solicitud de este tipo, ¡pero estaré encantado de ayudarte! No estoy seguro de lo que significa "difícil de tratar con todo el mundo todo el tiempo".

No me siento tan cómodo con los datos de IndexedDB

Bueno, es básicamente la única base de datos disponible localmente en los navegadores modernos (a excepción de localStorage, por supuesto), por lo que realmente no hay opciones para usar otra cosa.

¿Está diciendo que falló después de que la sincronización se solucionó hace un tiempo y abrió un problema al respecto que no llegó a una conclusión?

No, pregunté en Gitter y llegué a la conclusión de que debo limpiar todos mis datos en todos los navegadores que utilicé, ya que parece que funciona correctamente en un navegador limpio (donde nunca se ha usado Laverna).

No estoy seguro de lo que significa "difícil de tratar con todo el mundo todo el tiempo".

Cada navegador (o cliente de escritorio) que uso, cada vez que uso uno de ellos.

Bueno, es básicamente la única base de datos disponible localmente en los navegadores modernos (a excepción de localStorage, por supuesto), por lo que realmente no hay opciones para usar otra cosa.

Sí, sí, lo entiendo. Pero quise decir que no estoy acostumbrado a esta forma de sincronizar datos.

Me parece un problema de actualización. Entonces, cuando escribes ...

De hecho, nunca logré tener una sincronización de almacenamiento remoto completamente funcional

... ¿eso significa que todavía no funciona? Si ese es el caso, todavía estaría feliz de ayudar.

+1 para webDAV, mucho más estándar que una solución "solo Owncloud". Quedémonos abiertos, chicos.

En lugar de integrar una gran cantidad de nuevas soluciones hipster sin sentido como remoteStorage, ¿por qué no utilizar webDav de eficacia probada? Quiero decir, ¿cuál es el punto? ¿Por qué está obligando a los usuarios a ceder a su voluntad si el estándar de la industria es de facto otra cosa?

Decir que sí, rs está apoyando esto y eso es de poca utilidad para la mayoría de la gente. Pero no quiero usar otro protocolo que no me importa. Soporta Dropbox comercial, pero TENER las notas significa que no quiero guardarlas en un servidor de terceros. Simplemente no quiere entender que su software sobrevivirá solo si la gente quiere usarlo porque es amigable y flexible. En cambio, su objetivo es forzarlos a hacer algo que no quieren hacer. Todos estos son desarrolladores y personas conocedoras de la tecnología, simplemente no entiendes este simple hecho.

@technodrome No estoy hablando por los desarrolladores de Laverna, sino como desarrollador de remoteStorage.js. Tal vez no esté claro que mi intento de ayudar a la gente aquí (nunca probé nada más, si lees la historia con atención) no es lo mismo que decirle a la gente que se vaya, porque sus opiniones no son válidas ni son escuchadas por otra persona. Este es sin duda el lugar adecuado para expresarlos por lo que puedo ver, y no estoy seguro de por qué su primer comentario en este hilo es tan hostil. ¡Seamos amables entre nosotros, porque este es un trabajo voluntario no remunerado para todos nosotros!

En cambio, su objetivo es forzarlos a hacer algo que no quieren hacer.

No veo cómo proporcionar un software de código abierto, sin cargo, sea un arma fuerte para nadie. Si todos estos son desarrolladores y personas conocedoras de la tecnología, seguramente alguien puede contribuir con el soporte de WebDAV, si tiene sentido.

Entonces, veamos la viabilidad de WebDAV objetivamente. Aquí hay una lista (probablemente incompleta) de los problemas en los que puedo pensar, que deberían resolverse para que WebDAV se integre. (Estas son básicamente las razones por las que se creó el protocolo remoteStorage en primer lugar. De hecho, RS estaba usando WebDAV al principio, y los autores decidieron eliminarlo en favor de una API REST más simple, basada en el mundo real pruebas y experiencia con eso):

1. CORS

La forma en que funcionan los navegadores es que una aplicación no alojada como Laverna se conecta directamente al servidor desde JavaScript. Esto conlleva la restricción de que el servidor debe ofrecer encabezados de recursos de origen cruzado para todas las solicitudes y admitir OPCIONES solicitudes previas al vuelo para verbos HTTP que pueden manipular datos, como, por ejemplo, POST, PUT, DELETE. La mayoría de los servidores WebDAV no admiten esto. Por lo tanto, muchos servidores WebDAV serían incompatibles con Laverna de fábrica.

Problema: incluso si a uno no le importara que esos servidores sean incompatibles, ¿cómo detectaría una aplicación si hay soporte? En realidad, esto se hace mucho más difícil porque los navegadores no brindan intencionalmente los detalles del código JS sobre por qué falló la conexión, por lo que debería haber algún tipo de mecanismo de descubrimiento. Además, se debe explicar al usuario cuál podría ser exactamente la causa y que es posible que tenga que cambiar de servidor para usar la aplicación.

Solución en RS: el protocolo requiere CORS listo para usar. Además, el descubrimiento se maneja a través de Webfinger, donde la dirección del usuario puede devolver toda la información de configuración, pero también donde se pueden anunciar las capacidades adicionales del servidor.

Solución para WebDAV / Laverna simple: ¿ Alguna idea?

2. Permisos / Autorización

Los permisos deben manejarse en el lado del servidor y por cuenta en WebDAV, ya que no existe tal cosa integrada en el protocolo. No existe autorización de acceso a determinadas carpetas.

Solución en RS: OAuth 2.0, por lo que los desarrolladores de aplicaciones pueden decidir a qué parte del almacenamiento necesitan acceder, y los usuarios pueden ver fácilmente a qué parte y decidir otorgar acceso en un cuadro de diálogo simple.

Solución para WebDAV / Laverna simple: esto es básicamente imposible, pero, por supuesto, sería posible simplemente omitir esa función y dar voluntariamente a Laverna acceso a todos los datos. No es elegante, pero ciertamente no es un éxito para la implementación.

3. Asistencia sin conexión / móvil

Esto no es particularmente un problema de WebDAV o se resuelve solo en la especificación RS por completo. Pero para una aplicación web con capacidad para dispositivos móviles, no obstante, es un factor importante. Tanto las conexiones de escritorio como las móviles se caen con regularidad, y uno no querría que sus notas no se guarden debido a eso. Por lo tanto, se debe usar algún tipo de almacenamiento fuera de línea y sincronizar de manera inteligente con el servidor remoto (y, por supuesto, sin volver a autenticar después de cada gota si desea crear una buena experiencia de usuario).

Hay dos problemas aquí:

Problema 1: los servidores deben admitir Etags, por lo que, en primer lugar, se puede construir un mecanismo de sincronización

Solución en RS: Esto se resuelve en parte en el protocolo al requerir ETags tanto en los recursos de directorio como en sus listados de elementos, así como en los propios documentos individuales. En base a eso, uno puede construir mecanismos de sincronización usando encabezados HTTP como, por ejemplo, If-None-Match y respuestas como, por ejemplo, vacío 304 s por solicitar cosas que no han cambiado y 412 por negarse a sobrescribir algo que haya cambiado en un dispositivo diferente en un momento diferente.

Solución para WebDAV / Laverna simple: Desafortunadamente, el soporte de Etag es solo un DEBERÍA en la especificación de WebDAV, por lo que muchos servidores no lo admiten, y algunos incluso piden a sus usuarios explícitamente que desactiven el soporte, incluso si lo tienen, porque está implementado de una manera no funcional. (En realidad, este no es un problema fácil para un desarrollador de servidores; ciertamente puedo dar fe de ello). Pero de manera similar a CORS, es posible, por lo que la solución aquí volvería a depender del descubrimiento de características y guiar a los usuarios para configurar su servidor o decirles que tienen que cambiar a otro servidor. Afortunadamente, esto es mucho más fácil que con CORS, porque se puede detectar desde JS inspeccionando los encabezados de respuesta.

Problema 2: escriba un mecanismo de sincronización real o use una biblioteca que proporcione uno

Solución en RS: desde el principio, uno de los autores de especificaciones comenzó a crear una biblioteca de cliente de referencia para resolver este problema para las personas que desean integrar RS en sus aplicaciones. Todavía se está manteniendo y desarrollando y se ha probado en batalla en cientos de miles de diferentes conexiones, dispositivos, sistemas operativos, navegadores, en Cordova, etc. También se está utilizando en Laverna. El primer compromiso de eso se remonta a noviembre de 2010, por lo que ciertamente no es una "nueva solución hipster". Si hay errores con él, hay personas que están encantadas de ayudar con ellos, y cualquier comentario fue y siempre es apreciado (de ahí mis respuestas proactivas en este hilo).

Solución para WebDAV / Laverna simple: una posible solución sería una biblioteca personalizada enrollada a mano. El esfuerzo por crear, arreglar y mantener dicho código ciertamente empequeñecería los otros problemas que enumeré, y sin embargo, por supuesto, es muy posible hacerlo. El principal desafío que asumiría, aparte de literalmente mil otras cosas para implementar, es probablemente el comportamiento variable de los servidores WebDAV al final, especialmente. su implementación de Etag. Sin embargo, si conoce una biblioteca de este tipo (no conozco ninguna, y tampoco pude encontrar una, cuando volví a verificar ahora), sería muy posible resolver los otros problemas pendientes de alguna manera y proporcionar WebDAV a usuarios técnicos.

Disculpe y señale cualquier error o hecho incorrecto contenido en esta lista. Básicamente, escribí todo de mi cabeza. Transferiré esto a la wiki de RS pronto, y pediré a algunas personas que revisen / editen lo que escribí, ya que creo que esta es en realidad una explicación bastante útil de las diferencias entre WebDAV y RS, y cómo RS resuelve las cosas que WebDAV no lo ha hecho, cuando se trata de aplicaciones web del lado del cliente que se ejecutan completamente en el navegador (lo cual es comprensible, ya que las capacidades de la plataforma web no existían realmente en ese entonces y todo el concepto de aplicaciones web sin conexión primero no era un cosa).

@technodrome Si desea avanzar en su objetivo de obtener soporte de WebDAV, entonces señalar las posibles soluciones a cualquiera de estos problemas (o hechos que los anulan por completo) probablemente sería de gran ayuda.

Lo siento, pero si no puede comprender la perspectiva del usuario de sentido común porque siente que hiere sus sentimientos u opiniones, entonces el problema es usted. El software destinado a las personas es, por definición, utilizado por más de una persona, no solo por usted. Como tal, todos deben ser invitados a dar su opinión porque la lluvia de ideas y las ideas es lo que impulsa los proyectos hacia adelante. Y a juzgar por las personas que emiten +1 para webDav u otro soporte de protocolo estandarizado, no soy solo yo.

Estás tratando de tergiversar lo que dije y tomarte las cosas personalmente a pesar de que fueron pensadas como una opinión personal en un nivel general. Pero al grano, si un desarrollador no ofrece ningún método estandarizado para guardar los datos del usuario, entonces sí, está forzando al usuario a utilizar la preferencia del desarrollador.

Los usuarios expertos en tecnología no son iguales a los programadores. No saque conclusiones precipitadas solo porque se ajusta a su retórica.

Además, dije claramente que aprecio el trabajo y el esfuerzo y realmente lo hago. Simplemente no significa que esté ciegamente de acuerdo con todo solo porque tú lo dijiste. Es mi derecho como el suyo y hay millones de formas de resolver este problema. Por supuesto, está impulsando su producto, pero seamos un poco democráticos aquí y ofrezcamos una libertad de elección que se adapta a más personas, no solo a usted.

Si bien enumeró un montón de razones por las que no puede funcionar y por qué su solución RS es la cura para cada dolor, estoy seguro de que un punto final intermedio (¿aplicación Go?) Que se ejecuta como un demonio local (cliente, servidor) podría encargarse de la autorización y habilite una gran cantidad de posibilidades para integrar casi cualquier protocolo que desee. Seguramente trae menos dolor de cabeza que mantener una pila completa de tecnología, que puede o no ser olvidada y obsoleta en dos años.

Además, mi comentario no tenía la intención de demostrar que nadie estaba equivocado, solo para decir que existe un cierto estándar de la industria y hay una razón por la cual las cosas se convierten en ese estándar. Si no puede entender eso, me temo que no hay ningún argumento que pueda convencerlo de otra verdad que no sea la suya.

Bueno, leí buenos argumentos de ambos lados. Finalmente, ser dueño de mi almacenamiento fue un requisito para mí, y fui a turtl ya que el almacenamiento (encriptado) en el servidor es parte del núcleo del proyecto.
Como se mencionó anteriormente, si un producto no se adapta a todas sus necesidades, y en ese caso parece haber razones para ello (por supuesto, uno aún podría discutir), entonces busque algo más cercano a sus necesidades y requisitos.
Estoy seguro de que a muchas personas les parece bien alojar su archivo en Dropbox. No es necesario preocuparse, especialmente en un producto de código abierto. Sin embargo, comprendo y comparto la frustración, pero el código abierto tiene muchos planes comerciales y, a veces, no cumplen con nuestros requisitos. Solo tengo que lidiar con eso.

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

Lo siento, pero si no puede comprender la perspectiva del usuario de sentido común
porque sientes que hiere tus sentimientos u opiniones, entonces el problema
está contigo. El software destinado a las personas es, por definición, utilizado por
más de una persona, no solo tú. Como tal, todos deberían estar
invitado a dar una opinión porque la lluvia de ideas y las ideas es lo que
impulsa proyectos hacia adelante. Y a juzgar por las personas que emiten +1 para
webDav u otro soporte de protocolo estandarizado, no soy solo yo.

Estás tratando de tergiversar lo que dije y tomarte las cosas personalmente incluso
aunque fueron pensadas como una opinión personal en un nivel general. Sino
el punto - si un desarrollador no ofrece ningún método estandarizado de
guardar los datos del usuario, entonces sí, él / ella está presionando al usuario para
use la preferencia del desarrollador.

Los usuarios expertos en tecnología no son iguales a los programadores. No saltes a conclusiones
solo porque se ajusta a tu retórica.

Además, dije claramente que aprecio el trabajo y el esfuerzo y realmente lo hago.
Simplemente no significa que esté ciegamente de acuerdo con todo solo porque
tu dijiste. Es mi derecho como el tuyo y hay millones de formas
cómo solucionar este problema. Por supuesto que estás empujando tu
producto, pero seamos un poco democráticos aquí y ofrezcamos la libertad de
elección que se adapta a más personas, no solo a ti.

Si bien enumeró un montón de razones por las que no puede funcionar y por qué su
La solución RS es la cura para todos los dolores, estoy seguro de que un intermediario
endpoint (¿Ir a la aplicación?) que se ejecuta como un demonio local (cliente, servidor) podría
encargarse de la autorización y permitir una serie de posibilidades para
integre casi cualquier protocolo que desee. Seguramente trae menos
dolor de cabeza que mantener una pila completa de tecnología, que puede o puede
No será olvidado y obsoleto en dos años.

Además, mi comentario no tenía la intención de demostrar que nadie estaba equivocado, solo para decir
hay un cierto estándar de la industria y hay una razón por la que las cosas
convertirse en un estándar. Si no puedes entender eso, tengo miedo
no hay argumentación que pueda convencerte de otra verdad
que el tuyo.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/Laverna/laverna/issues/6#issuecomment -282279742

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

Como tal, todos deben ser invitados a dar su opinión porque la lluvia de ideas y las ideas es lo que impulsa los proyectos hacia adelante. Y a juzgar por las personas que emiten +1 para webDav u otro soporte de protocolo estandarizado, no soy solo yo.

¡Sí! Dije exactamente eso y luego dediqué tiempo y esfuerzo a señalar lo que creo que debería resolverse para cumplir su deseo. No modifiqué nada para "encajar en mi agenda", y los invito activamente a usted ya cualquier otra persona a señalar cualquier error contenido en mi análisis objetivo y también lo invité a ayudar a avanzar en la implementación de su propia preferencia / idea.

Desafortunadamente, no es fácil encontrar argumentos sustanciales o nuevos hechos entre las acusaciones en su comentario de seguimiento. Pero un párrafo contiene al menos una idea:

Estoy seguro de que un punto final intermedio (¿aplicación Go?) Que se ejecute como un demonio local (cliente, servidor) podría encargarse de la autorización y permitir una gran cantidad de posibilidades para integrar casi cualquier protocolo que desee.

Así que sí, eso, por supuesto, sería posible en teoría. El problema con eso es que entra totalmente en conflicto con sus propias opiniones y argumentos en el mismo párrafo:

Seguramente trae menos dolor de cabeza que mantener una pila completa de tecnología, que puede o no ser olvidada y obsoleta en dos años.

Su idea significaría exactamente eso: crear, probar y mantener una pila de tecnología completamente nueva ("cliente, servidor") para que la aplicación web pueda almacenar datos de forma remota y sincronizarlos entre dispositivos. Aparte del problema de inventar y mantener esta pila completamente nueva, también sería bastante difícil ejecutar ese programa local en todos sus dispositivos, sobre todo en los móviles.

Además, mi comentario no tenía la intención de demostrar que nadie estaba equivocado, solo para decir que existe un cierto estándar de la industria y hay una razón por la cual las cosas se convierten en ese estándar.

¡Estoy completamente de acuerdo con eso! Y expliqué en detalle por qué WebDAV no se

En realidad, es un protocolo bastante simple y lo opuesto a una "pila de tecnología". En caso de que no haya visto la explicación rápida de sus partes, puede encontrarla en este sitio web . - Además, con respecto a "webDav u otro soporte de protocolo estandarizado", eso es exactamente lo que RS debe ser .

Ahora, por supuesto, puede sentirse mal acerca de que WebDAV no sea una solución demasiado viable para las aplicaciones web del lado del cliente, pero eso de alguna manera no cambia los hechos en cuestión, ni me convierte en un idiota egoísta por señalarlos. Por favor, por favor , hablemos de esto de manera racional y evitemos las acusaciones personales. Realmente solo estoy tratando de ayudar, y no hay absolutamente ninguna necesidad de negatividad. Nuevamente: en realidad estoy tratando de ayudarlo a lograr su objetivo, y definitivamente no estoy argumentando que RS sea una solución exclusiva en absoluto. Si alguien puede encontrar otra solución que logre los mismos objetivos, entonces soy la última persona en argumentar en contra de ella en base a una preferencia personal o ideología.

Laverna, como aplicación web, solo admite HTTP como protocolo de transferencia y requiere CORS para que todo funcione. Sin embargo, por alguna razón, la gente está proponiendo cosas como BitTorrent Sync o WebDAV, uno de los cuales no se ejecuta en HTTP y ninguno tiene CORS como parte de su especificación. De hecho, el primero ni siquiera tiene una especificación, es un protocolo propietario. @technodrome incluso va tan lejos como para llamar al uso de WebDAV "perspectiva de usuario de sentido común", aunque, nuevamente, usar WebDAV desde una aplicación Javascript en el navegador simplemente no funciona en el caso general y, por lo tanto, no tiene sentido, independientemente de la perspectiva. . La charla sobre el uso de un proxy intermedio para agregar encabezados CORS tampoco coincide con mi idea de una buena experiencia de usuario.

Creo que esto realmente muestra que esta discusión está dominada principalmente por personas que desean "libertad general de software" y descartan los nombres de algunos protocolos establecidos, no personas que realmente han examinado seriamente cualquiera de esas opciones desde una perspectiva técnica y han determinado si son la herramienta adecuada para el trabajo. Una vez más me gustaría llamar a cabo @technodrome, que además tiene una rabieta porque él (comprensiblemente) percibe @skddc 's defensa de RemoteStorage como chelín empujando su propia agenda, al mismo tiempo @skddc es el primero en este hilo para hacer un argumento decente para el protocolo que está proponiendo.

Quizás deberíamos admitir que incluso después de los tres años que se ha abierto este número, simplemente no existe un estándar para esto. Lo que nos deja con tres opciones:

1. Apueste por el almacenamiento remoto, aún no es un estándar
2. Use WebDAV de todos modos, pero requiera encabezados CORS. Efectivamente, esto significa solo soporte para NextCloud y ownCloud.
3. Escriba un complemento NextCloud personalizado, con API personalizada

Anuncio 1: remoteStorage como protocolo es bastante bueno, pero no creo que la biblioteca cliente esté allí todavía. De hecho, la última experiencia que tuve con remoteStorage.js (la biblioteca cliente) no fue buena. Todo funcionó, sin embargo, todavía había errores menores en todas partes y simplemente no considero que la API de "modelado de datos" de alto nivel sea utilizable. Sin embargo, la última parte no debería importar, dado que puede escribir su propio modelo de datos y leer y escribir archivos sin procesar.

Anuncio 2: Esto funciona totalmente, pero ahora se ha limitado a NextCloud / ownCloud mientras tiene que lidiar con la monstruosa complejidad de WebDAV. Creo que puedo hablar por todos los que alguna vez trabajaron con ese protocolo cuando digo que el uso de WebDAV solo por usar un estándar no vale la pena si el usuario no se beneficia de él.

Dado que Laverna ya tiene soporte de almacenamiento remoto, supongo que invertir más tiempo en arreglar la biblioteca cliente rs.js es una buena manera de seguir adelante, aunque probablemente necesitemos soporte de NextCloud para que cualquiera pueda usar ese backend. Una aplicación especializada de NextCloud también es una buena opción, en mi opinión, aunque no alcanza el objetivo de tener un estándar aún más.

Hola,
Informe a https://github.com/Laverna/laverna/issues/971#issuecomment -411423965 que explica el estado de este proyecto.

Que tengas un buen día / noche,
Salud,
Nissar