Laverna: Sincronizar com armazenamento não comercial

Ou Owncloud ...

Olhe para vole.cc. Eles têm um servidor baseado em Go personalizado que salva coisas em arquivos. Você provavelmente poderia apenas conectar a ele para facilitar o armazenamento local.

Sim, ligar a uma nuvem própria será perfeito

Seria interessante sincronizar com o OwnCloud.

Uma opção de sincronização do Bittorrent também seria boa.

1 para owncloud

Como @michielbdejong escreveu sobre StackEdit , lá dentro pode-se encontrar abordagens interessantes para um conector de armazenamento de dados multi-provedor generalizado.

Além disso, remoteStorage agora também está

1 para owncloud!

+1

+1 Cozy.io, Owncloud, Bittorrent Sync. Qualquer um desses seria ótimo!

Acho que esse segmento demonstra a necessidade de um método padronizado que conecte Laverna a provedores de armazenamento. Todo mundo tem seu próprio programa preferido para hospedar dados pessoais. Não há nada de errado com isso, mas agora que os desenvolvedores forneceram meios comerciais viáveis ​​(Dropbox) e não comerciais (RemoteStorage) de fazer isso, eu preferiria que eles se concentrassem na expansão de outros aspectos do projeto. Oferecer aos usuários as ferramentas para se conectarem por conta própria economizaria tempo a longo prazo.

Também gostaria de sincronizar o Google Drive (ou até mesmo sincronizar o Google Keep)

+1 - Eu também concordo com @andtheWings.

Mas, por enquanto, acho que adicionar 2 serviços: GoogleDrive (principal, já que a maioria das pessoas já o está usando) e OwnCloud (alternativa não comercial do Dropbox amplamente usada) cobriria uma base de usuários muito grande e abriria notas do Laverna para muito mais pessoas.

Isso pode realmente expandir a comunidade.

Observe que o remoteStorage traz a sincronização do Google Drive e Dropbox pronta para uso. Verifique em 5apps.com .

_Editar: _ Bittorrent Sync no navegador parece uma aventura.

@almereyda Err, você poderia ser mais específico: como posso armazenar minhas anotações por meio de remoteData no Google Drive com 5apps.com?

@almereyda Se por 'sincronização

Mas meu objetivo é divulgar o uso do Laverna e torná-lo facilmente adotado pelo público em geral. Eu acredito que o Google Drive é o elo que faltava lá. A maioria das pessoas tem uma conta do Google e podem usar diretamente o Google Drive em vez de reiniciar com outro serviço de inscrição e configuração.

Uma vez que a maioria das pessoas aqui prefere OwnCloud (incluindo eu) e é aberto / não comercial, eu definitivamente recomendo uma opção para que seja desenvolvido primeiro no Google Drive.

Eu escolhi usar Laverna, esperando que pudesse evoluir para algo capaz de substituir Evernone. Estou usando o OwnCloud para substituir o Dropbox, Google Drive ect. Realizei essas etapas para não precisar mais depender desses serviços e concordar com seus termos. Eu entendo que adicionar a opção de sincronizar com serviços como o Dropbox aumentaria a popularidade (e eu encorajo isso), mas para mim pessoalmente não se encaixa.

@SandeepPinge

Viva!

GDrive para as massas / Owncloud para os reais!
imho, Owncloud / GDrive é uma excelente combinação de software livre / proprietário.

Estou executando o Laverna em meu próprio espaço na web. Por que não consigo salvar os dados (criptografados) diretamente no servidor da web? Ou posso implementar RemoteStorage no meu servidor da web? Não tenho acesso SSH!

Acho que o Laverna não foi pensado para ser um aplicativo hospedado, mas executa localmente com armazenamento local dos arquivos. Eu preferiria uma solução hospedada também, pois torna a sincronização entre dispositivos muito mais fácil.

Local?
Se eu quiser notas locais, uso notepad.exe.
;-)

O Laverna foi projetado para não ser hospedado, ou seja, para que os dados sejam armazenados localmente no navegador por padrão. Mais informações aqui: https://unhosted.org/

"Nenhum de nós pode obter acesso aos seus dados pessoais porque estamos usando IndexedDB e localStorage. Na verdade, todas as suas informações serão armazenadas apenas no lado do cliente."
Isso significa, afaik que os dados são armazenados localmente (em uma pasta que pode ser acessada pelo navegador). Mas pode-se usar o Dropbox (e esperançosamente outras alternativas em breve) para sincronizar as notas.

Pessoal, observe que remoteStorage agora está disponível na Cozy Cloud , para que você possa girar facilmente sua própria instância.

Além disso, como o Laverna suporta remoteStorage, mas parece uma especificação antiga, há um trabalho em andamento para integrá-lo ao ownCloud também.

@michielbdejong @skddc Você poderia dar uma olhada rápida no Laverna e inspecionar por que ele falha ao sincronizar com 5apps? Costumava funcionar, acho que antes do lançamento do 0.10. Eles simplesmente não atualizaram o cliente? Faria sentido submodule it?

Não estou familiarizado com o Marionette ou com o código-fonte deste aplicativo. No entanto, estamos sempre aqui para ajudar e responder a todas as perguntas, tanto gerais quanto para códigos concretos.

Quem mantém o suporte RS neste aplicativo (ou mantém o aplicativo em geral): estamos muito ansiosos para recebê-lo em #remotestorage no Freenode ou conversar sobre qualquer coisa nos fóruns ou GitHub.

Eu adicionaria Syncthing (https://syncthing.net/) e Seafile (http://seafile.com/en/home/) também.

1+ para OwnCloud!

1+ OwnCloud

Owncloud seria ótimo.

Owncloud +1

owncloud +1

owncloud +1
Estou exatamente na mesma situação que @Putdeksel
Ter o controle total de suas anotações usando seu próprio sistema de armazenamento seria incrível.

Ter o controle total de suas anotações usando seu próprio sistema de armazenamento seria incrível.

Sim, é _é_ incrível e já é possível através do suporte RemoteStorage do Laverna. Você nem mesmo está vinculado a uma única implementação de servidor, mas qualquer servidor que use o protocolo RS pode armazenar suas anotações. ;)

@skddc Eu não olhei para RemoteStorage para ser honesto. Mas, infelizmente, pelo que posso ver, não parece ser compatível com o servidor que recebi do meu provedor. Esperançosamente isso acontecerá no futuro próximo!

+1 ownCloud.

A sincronização OwnCloud seria ótima.

1 para owncloud!

Posso sugerir algo para todos os usuários do ownCloud aqui:

Seria _muito_ mais fácil para os desenvolvedores de aplicativos (não apenas deste aplicativo) oferecer suporte ao ownCloud, se o ownCloud fosse compatível com um protocolo aberto para armazenamento de dados por usuário. Este aplicativo já suporta remoteStorage, então se ownCloud fosse para suportar remoteStorage, em vez de os desenvolvedores precisarem adicionar suporte especial para ownCloud em seus aplicativos, todos os aplicativos habilitados para remoteStorage também funcionariam automaticamente com ownCloud agindo como o servidor de armazenamento remoto.

Portanto, acho que seria ótimo se você pedisse / votasse ou contribuísse com o suporte de RS para o ownCloud em si!

Seguindo essa conversa por alguns anos já, eu tenho que apoiar
A última observação de @skddc .

Em 25 de julho de 2016 às 14:22, Sebastian Kippe [email protected] escreveu:

Posso sugerir algo para todos os usuários do ownCloud aqui:

Seria _muito_ mais fácil para os desenvolvedores de aplicativos (não apenas deste aplicativo)
suporte ownCloud, se ownCloud fosse oferecer suporte a um protocolo aberto para por usuário
armazenamento de dados. Este aplicativo já suporta remoteStorage, então se ownCloud fosse
para suportar remoteStorage, em vez de os desenvolvedores precisarem adicionar
suporte ownCloud para seus aplicativos, então todos os aplicativos habilitados para remoteStorage
automaticamente também funciona com ownCloud atuando como o servidor de armazenamento remoto.

Portanto, acho que seria ótimo se você pedisse / votasse ou contribuísse com RS
suporte para o próprio ownCloud!

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/Laverna/laverna/issues/6#issuecomment -234938265 ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/ABka_MqpAc9pic432ehmtZ58HBUTh2Iyks5qZKqOgaJpZM4BqQ_m
.

Eu +1 este problema!

Hmm, seria difícil implementar o webDAV, pois isso poderia ser visto como um padrão aberto que permitirá que o laverna seja conectado a dezenas de provedores de armazenamento diferentes?

Por que não armazenar os dados em um diretório local especificado e as pessoas podem sincronizar seus dados na nuvem por meio de clientes de sincronização como Seafile ou clientes ownCloud Desktop?

Por que não armazenar os dados em um diretório local especificado e as pessoas podem sincronizar seus dados na nuvem por meio de clientes de sincronização como Seafile ou clientes ownCloud Desktop?

Isso só é possível em uma potencial versão empacotada do aplicativo, mas não na web. É também o que remoteStorage resolve e por que é usado em Laverna.

Alguém aqui abriu um problema do ownCloud sobre a integração do remoteStorage até agora? Eu só posso enfatizar como isso seria ótimo e que Laverna suportaria automaticamente o ownCloud.

Isso só é possível em uma potencial versão empacotada do aplicativo, mas não na web. É também o que remoteStorage resolve e por que é usado em Laverna.

Na verdade, nunca consegui ter uma sincronização remoteStorage totalmente funcional. Eu tentei muitas vezes, e é muito difícil lidar com todo mundo todas as vezes. Não estou tão confortável com os dados IndexedDB ...

Estou bastante familiarizado com as sincronizações de DAVs. @wwebfor me disse que há outra maneira de sincronizar no forno, pensou.

Na verdade, nunca consegui ter uma sincronização remoteStorage totalmente funcional. Eu tentei muitas vezes, e é muito difícil lidar com todo mundo todas as vezes.

Você está dizendo que ele falhou depois que as correções de sincronização um tempo atrás e você abriu um problema sobre isso, que não chegou a uma conclusão?

Não vi nenhum desses problemas ou solicitações, mas ficaria feliz em ajudá-lo! Não tenho certeza do que significa "difícil lidar com todos sempre".

Não estou tão confortável com os dados IndexedDB

Bem, é basicamente o único banco de dados disponível localmente em navegadores modernos (exceto para localStorage, é claro), então não há realmente opções para usar outra coisa.

Você está dizendo que ele falhou depois que as correções de sincronização um tempo atrás e você abriu um problema sobre isso, que não chegou a uma conclusão?

Não, perguntei no Gitter e cheguei à conclusão de que devo limpar todos os meus dados em cada navegador que usei, pois parece que funciona corretamente no navegador limpo (onde Laverna nunca foi usado).

Não tenho certeza do que significa "difícil lidar com todos sempre".

Cada navegador (ou cliente de desktop) que utilizo, cada vez que utilizo um deles.

Bem, é basicamente o único banco de dados disponível localmente em navegadores modernos (exceto para localStorage, é claro), então não há realmente opções para usar outra coisa.

Sim, sim, entendo. Mas eu quis dizer que não estou acostumado com essa forma de sincronizar dados.

Parece um problema de atualização para mim. Então, quando você escreve ...

Na verdade, nunca consegui ter uma sincronização remoteStorage totalmente funcional

... isso significa que ainda não funciona? Se for esse o caso, terei todo o gosto em ajudar.

+1 para webDAV, muito mais padrão do que uma solução "Somente Owncloud". Vamos ficar abertos, pessoal.

Em vez de integrar um monte de novas soluções hipster sem sentido como remoteStorage, por que não usar o webDav testado e comprovado? Quero dizer, qual é o ponto? Por que você está forçando os usuários a obedecerem à sua vontade se o padrão da indústria é de fato outra coisa?

Dizer que sim, o rs está apoiando isso e isso é de pouca utilidade para a maioria das pessoas. Mas não quero usar mais um protocolo com o qual não me interessa. Você oferece suporte ao Dropbox comercial, mas TER as notas significa que não quero salvá-las em um servidor de terceiros. Você simplesmente não quer entender que seu software sobreviverá apenas se as pessoas quiserem usá-lo devido à sua facilidade e flexibilidade. Em vez disso, seu objetivo é forçá-los a fazer algo que eles não querem fazer. Todos esses são desenvolvedores e pessoas com experiência em tecnologia, você simplesmente não entende esse fato simples.

@technodrome Não estou falando pelos desenvolvedores Laverna, mas sim como desenvolvedor remoteStorage.js. Talvez não esteja claro que tentar ajudar as pessoas aqui (nunca tentei outra coisa, se você leu bem a história) não seja o mesmo que mandar as pessoas irem embora, porque suas opiniões não são válidas ou ouvidas por outra pessoa. Este é certamente o lugar certo para expressá-los, tanto quanto posso ver, e não tenho certeza por que seu primeiro comentário neste tópico é tão hostil. Sejamos todos simpáticos uns com os outros, porque este é um trabalho voluntário não remunerado para todos nós!

Em vez disso, você visa fortalecê-los em algo que eles não querem fazer

Não vejo como fornecer um software de código aberto, gratuito, está armando alguém. Se todos são desenvolvedores e pessoas com experiência em tecnologia, certamente alguém pode contribuir com o suporte WebDAV, se isso faz sentido?

Então, vamos examinar a viabilidade do WebDAV objetivamente. Aqui está uma lista (provavelmente incompleta) dos problemas nos quais posso pensar, que precisariam ser resolvidos para que o WebDAV fosse integrado. (Estas são basicamente as razões pelas quais o protocolo remoteStorage foi criado em primeiro lugar. Na verdade, RS estava usando WebDAV no início, e os autores decidiram removê-lo em favor de uma API REST mais simples, baseada no mundo real teste e experiência com isso):

1. CORS

A maneira como os navegadores funcionam é que um aplicativo não hospedado como o Laverna se conecta diretamente ao servidor a partir de JavaScript. Isso traz consigo a restrição de que o servidor deve oferecer cabeçalhos de Cross Origin Resource para todas as solicitações e oferecer suporte a solicitações OPTIONS pré-voo para verbos HTTP que podem manipular dados, como, por exemplo, POST, PUT, DELETE. A maioria dos servidores WebDAV não oferece suporte para isso. Portanto, muitos servidores WebDAV seriam incompatíveis com o Laverna fora da caixa.

Problema: mesmo que ninguém se importasse com a incompatibilidade desses servidores, como um aplicativo detectaria se há suporte? Na verdade, isso é muito mais difícil porque os navegadores intencionalmente não fornecem detalhes do código JS sobre o motivo da falha na conexão, portanto, seria necessário algum tipo de mecanismo de descoberta. Além disso, deve ser explicado ao usuário o que exatamente poderia ser a causa e que ele pode ter que trocar de servidor para usar o aplicativo.

Solução em RS: o protocolo requer CORS pronto para uso. Além disso, a descoberta é feita através do Webfinger, onde o endereço do usuário pode retornar todas as informações de configuração, mas também onde recursos extras do servidor podem ser anunciados.

Solução para WebDAV / Laverna simples: Alguma ideia?

2. Permissões / Autorização

As permissões devem ser tratadas no lado do servidor e por conta no WebDAV, já que não existe tal coisa embutida no protocolo. Não existe autorização de acesso a certas pastas.

Solução em RS: OAuth 2.0, para que os desenvolvedores de aplicativos possam decidir a qual parte do armazenamento eles precisam acessar e os usuários possam ver facilmente qual é essa parte e decidir conceder acesso em uma caixa de diálogo simples.

Solução para WebDAV / Laverna simples: Isso é basicamente impossível, mas é claro que seria possível simplesmente pular esse recurso e fornecer voluntariamente ao Laverna acesso a todos os seus dados. Não é elegante, mas certamente não é um obstáculo para a implementação.

3. Suporte offline / móvel

Este não é um problema específico de WebDAV ou resolvido apenas na especificação RS. Mas, para um aplicativo da web compatível com dispositivos móveis, não deixa de ser um fator importante. As conexões de desktop e móvel caem regularmente, e ninguém gostaria que suas anotações não fossem salvas por causa disso. Portanto, algum tipo de armazenamento offline precisa ser usado e sincronizado de forma inteligente com o servidor remoto (e, claro, sem reautenticação após cada queda, se você quiser criar uma boa experiência do usuário).

Existem dois problemas aqui:

Problema 1: os servidores precisam oferecer suporte a Etags, para que seja possível construir um mecanismo de sincronização em primeiro lugar

Solução no RS: isso é parcialmente resolvido no protocolo, exigindo ETags nos recursos de diretório e em suas listagens de itens, bem como nos próprios documentos. Com base nisso, pode-se construir mecanismos de sincronização usando cabeçalhos HTTP como, por exemplo, If-None-Match e respostas como, por exemplo, vazio 304 s para solicitar coisas que não mudaram e 412 para recusar sobrescrever algo que foi alterado em um dispositivo diferente em um momento diferente.

Solução para WebDAV / Laverna simples: Infelizmente, o suporte Etag é apenas OBRIGATÓRIO na especificação WebDAV, muitos servidores não o suportam e alguns até pedem explicitamente a seus usuários que desliguem o suporte, mesmo que o tenham, porque está implementado de uma forma sem desempenho. (Na verdade, este não é um problema fácil para um desenvolvedor de servidor; certamente posso atestar isso). Mas semelhante ao CORS, é possível, então a solução aqui seria novamente descer para a descoberta de recursos e orientar os usuários a configurar seu servidor ou dizer a eles que precisam mudar para outro servidor. Felizmente, isso é muito mais fácil do que com CORS, porque pode-se detectar isso no JS inspecionando os cabeçalhos de resposta.

Problema 2: escreva um mecanismo de sincronização real ou use uma biblioteca que forneça um

Solução no RS: muito cedo, um dos autores das especificações começou a criar uma biblioteca de cliente de referência para resolver esse problema para pessoas que desejam integrar o RS em seus aplicativos. Ele ainda está sendo mantido e desenvolvido e foi testado em centenas de milhares de diferentes conexões, dispositivos, sistemas operacionais, navegadores, em Cordova e assim por diante. Também está sendo usado em Laverna. O primeiro commit disso remonta a novembro de 2010, então certamente não é uma "nova solução hipster". Se houver bugs com ele, existem pessoas que ficarão felizes em ajudar com eles, e qualquer feedback foi e sempre será apreciado (daí minhas respostas proativas neste tópico).

Solução para WebDAV / Laverna simples: Uma solução possível seria uma biblioteca personalizada feita à mão. O esforço para criar, consertar e manter tal código certamente ofuscaria os outros problemas que listei e, ainda assim, é muito possível fazer isso. O principal desafio que eu assumiria, além de literalmente mil outras coisas para implementar, é provavelmente o comportamento variável dos servidores WebDAV no final, esp. sua implementação Etag. No entanto, se você conhece tal biblioteca (não conheço nenhuma, e também não consegui encontrar, quando verifiquei novamente há pouco), seria muito possível resolver os outros problemas pendentes de alguma forma e fornecer WebDAV para usuários técnicos.

Por favor, desculpe e aponte quaisquer erros ou fatos errados contidos nesta lista. Eu basicamente escrevi tudo de cima da minha cabeça. Vou transferir isso para a wiki do RS em breve e pedir a algumas pessoas que revisem / editem o que escrevi, pois acho que esta é, na verdade, uma explicação bastante útil das diferenças entre WebDAV e RS, e como RS resolve coisas que WebDAV não, quando se trata de aplicativos da Web do lado do cliente que são executados inteiramente no navegador (o que é compreensível, já que os recursos da plataforma da Web não existiam realmente naquela época e todo o conceito de aplicativos da Web que priorizam offline não era um coisa).

@technodrome Se você quiser progredir em sua meta de obter suporte WebDAV, apontar possíveis soluções para qualquer um desses problemas (ou fatos que os anulem totalmente) provavelmente seria um bom caminho.

Desculpe, mas se você não consegue entender a perspectiva do usuário de bom senso porque acha que fere seus sentimentos ou opiniões, então o problema é com você. O software destinado a pessoas é por definição usado por mais de uma pessoa - não apenas você. Como tal, todos devem ser convidados a oferecer uma opinião porque o brainstorming e as ideias são o que impulsiona os projetos. E a julgar pelas pessoas que emitem +1 para webDav ou outro suporte de protocolo padronizado, não sou só eu.

Você está tentando distorcer o que eu disse e levar as coisas para o lado pessoal, mesmo que elas significassem uma opinião pessoal em um nível geral. Mas direto ao ponto - se um desenvolvedor não oferece nenhum método padronizado de salvar os dados do usuário, então sim - ele está armando o usuário para usar a preferência do desenvolvedor.

Usuários experientes em tecnologia não se igualam a programadores. Não tire conclusões precipitadas só porque se encaixa na sua retórica.

Além disso, eu disse claramente que aprecio o trabalho e o esforço, e realmente agradeço. Só não significa que concordarei cegamente com tudo só porque você disse. É meu direito assim como é seu e há milhões de maneiras de resolver esse problema. É claro que você está promovendo seu produto, mas vamos ser um pouco democráticos aqui e oferecer uma liberdade de escolha que se adapte a mais pessoas, não apenas a você.

Embora você tenha listado uma série de razões pelas quais ele não pode funcionar e por que sua solução RS é a cura para todas as dores, tenho certeza de que um endpoint intermediário (aplicativo Go?) Em execução como um daemon local (cliente, servidor) poderia cuidar da autorização e permite uma série de possibilidades para integrar praticamente qualquer protocolo que você deseja. Certamente traz menos dor de cabeça do que manter uma pilha inteira de tecnologia, que pode ou não ser esquecida e obsoleta em dois anos.

Além disso, meu comentário não teve a intenção de provar que alguém estava errado, apenas para dizer que há um certo padrão da indústria e há uma razão pela qual as coisas se tornaram tal padrão. Se você não consegue entender isso, receio que não haja argumentação que possa convencê-lo de qualquer outra verdade além da sua.

Bem, eu li bons argumentos de ambos os lados. Eventualmente, possuir meu armazenamento era um requisito para mim, e fui para o turtl, pois o armazenamento (criptografado) no servidor é parte do núcleo do projeto.
Como mencionado anteriormente, se um produto não atende a todas as suas necessidades e, nesse caso, parece haver razões para isso (que é claro que ainda podemos questionar), então procure algo mais próximo de suas necessidades e requisitos.
Tenho certeza de que muitas pessoas concordam em hospedar seus arquivos no Dropbox. Não há necessidade de se preocupar muito, especialmente em um produto de código aberto. No entanto, entendo e compartilho a frustração, mas o código aberto tem muitos planos de negócios e, às vezes, eles não atendem aos nossos requisitos. Apenas tenho que lidar com isso.

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

Desculpe, mas se você não consegue entender a perspectiva do usuário de bom senso
porque você sente que fere seus sentimentos ou opiniões, então o problema
é com você. O software destinado a pessoas é por definição usado por
mais de uma pessoa - não apenas você. Como tal, todos deveriam ser
convidados a oferecer uma opinião porque brainstorming e ideias é o que
empurra projetos para frente. E a julgar pelas pessoas que emitiram +1 para
webDav ou outro suporte de protocolo padronizado, não sou só eu.

Você está tentando distorcer o que eu disse e levar as coisas para o lado pessoal, mesmo
embora pretendessem ser uma opinião pessoal em um nível geral. Mas para
o ponto - se um desenvolvedor não oferece nenhum método padronizado de
salvando os dados do usuário, então sim - ele / ela está armando fortemente o usuário para
use a preferência do desenvolvedor.

Usuários experientes em tecnologia não se igualam a programadores. Não tire conclusões precipitadas
só porque se encaixa na sua retórica.

Além disso, eu disse claramente que aprecio o trabalho e o esforço, e realmente agradeço.
Só não significa que vou concordar cegamente com tudo só porque
você disse então. É meu direito assim como é seu e há milhões de maneiras
como resolver esse problema. Claro que você está forçando o seu
produto, mas vamos ser um pouco democráticos aqui e oferecer uma liberdade de
escolha que se adapta a mais pessoas, não apenas você.

Embora você tenha listado uma série de razões pelas quais ele não pode funcionar e por que seu
A solução RS é a cura para todas as dores, tenho certeza de que é um intermediário
endpoint (aplicativo Go?) em execução como um daemon local (cliente, servidor) pode
cuidar da autorização e permitir uma série de possibilidades para
integre praticamente qualquer protocolo que desejar. Certamente traz menos
dor de cabeça do que manter toda uma pilha de tecnologia, que pode ou pode
não será esquecido e obsoleto em dois anos.

Além disso, meu comentário não tinha a intenção de provar que alguém estava errado, apenas para dizer
há um certo padrão da indústria e há uma razão pela qual as coisas
tornar-se um padrão. Se você não consegue entender isso, estou com medo
não há argumentação que possa convencê-lo de qualquer outra verdade
do que o seu.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub:
https://github.com/Laverna/laverna/issues/6#issuecomment -282279742

-
Enviado para meu aplicativo Android com K-9 Mail. Veuillez excuser ma brièveté.

Como tal, todos devem ser convidados a oferecer uma opinião porque o brainstorming e as ideias são o que impulsiona os projetos. E a julgar pelas pessoas que emitem +1 para webDav ou outro suporte de protocolo padronizado, não sou só eu.

Sim! Eu disse exatamente isso e, em seguida, gastei tempo e esforço para apontar o que acho que precisaria ser resolvido a fim de realizar seu desejo. Eu não torci nada para "encaixar na minha agenda", e ativamente convido você e qualquer outra pessoa a apontar quaisquer erros contidos em minha análise objetiva e também convidei você a ajudar no progresso da implementação de sua própria preferência / ideia.

Infelizmente, não é fácil encontrar argumentos substanciais ou novos fatos entre as acusações em seu comentário de acompanhamento. Mas um parágrafo contém pelo menos uma ideia:

Tenho certeza de que um endpoint intermediário (aplicativo Go?) Em execução como um daemon local (cliente, servidor) pode cuidar da autorização e permitir uma série de possibilidades para integrar praticamente qualquer protocolo que você desejar

Então, sim, isso seria possível em teoria. O problema com isso é que conflita totalmente com suas próprias opiniões e argumentos no mesmo parágrafo:

Certamente traz menos dor de cabeça do que manter uma pilha inteira de tecnologia, que pode ou não ser esquecida e obsoleta em dois anos.

Sua ideia significaria exatamente isso: criar, testar e manter uma nova pilha de tecnologia ("cliente, servidor") para que o aplicativo da web seja capaz de armazenar dados remotamente e sincronizá-los entre dispositivos. Além do problema de inventar e manter toda essa nova pilha, também seria bastante difícil executar esse programa local em todos os seus dispositivos, principalmente os móveis.

Além disso, meu comentário não teve a intenção de provar que alguém estava errado, apenas para dizer que há um certo padrão da indústria e há uma razão pela qual as coisas se tornaram tal padrão.

Eu concordo completamente com isso! E eu expliquei longamente por que o WebDAV de fato não se tornou aquele padrão para aplicativos da web do lado do cliente, e por que o protocolo RS foi criado --inicialmente com WebDAV como API - como um novo padrão para tornar por usuário, auto-hospedado armazenamento possível para este tipo exato de aplicações.

Na verdade, é um protocolo bastante simples e o oposto de uma "pilha de tecnologia". Caso você não tenha visto a explicação rápida de suas partes, poderá encontrá-la neste site . - Além disso, em relação ao "webDav ou outro suporte de protocolo padronizado", é exatamente isso que RS pretende ser .

Agora, é claro que você pode ter sentimentos negativos sobre o WebDAV não ser uma solução excessivamente viável para aplicativos da web do lado do cliente, mas isso não muda de alguma forma os fatos em questão, ou me torna um idiota egoísta por apontá-los. Por favor , vamos discutir isso racionalmente e manter as acusações pessoais fora disso. Na verdade, estou apenas tentando ajudar e não há necessidade de negatividade. Novamente: Na verdade, estou tentando ajudá-lo a atingir seu objetivo e, definitivamente, não estou defendendo que o RS seja uma solução exclusiva. Se alguém puder propor qualquer outra solução, que atinja os mesmos objetivos, então sou a última pessoa a argumentar contra isso com base em preferência pessoal ou ideologia.

Laverna, como uma aplicação web, só pode suportar HTTP como protocolo de transferência e requer CORS para que tudo funcione. Ainda assim, por algum motivo, as pessoas estão propondo coisas como BitTorrent Sync ou WebDAV, um dos quais não roda em HTTP e nenhum dos quais tem CORS como parte de sua especificação. Na verdade, o primeiro nem mesmo tem uma especificação, é um protocolo proprietário. O @technodrome chega a chamar o uso de WebDAV de "perspectiva do usuário de bom senso", embora, novamente, usar WebDAV de um aplicativo Javascript no navegador simplesmente não funciona no caso geral e, portanto, não faz sentido, independentemente da perspectiva . A conversa sobre o uso de um proxy intermediário para adicionar cabeçalhos CORS também não corresponde à minha ideia de uma boa UX.

Acho que isso realmente mostra que essa discussão é principalmente dominada por pessoas que desejam "liberdade geral de software" e descartam os nomes de alguns protocolos estabelecidos, não pessoas que realmente analisaram seriamente qualquer uma dessas opções de uma perspectiva técnica e determinaram se eles são a ferramenta certa para o trabalho. Mais uma vez eu gostaria de chamar @technodrome, que além joga uma birra porque ele (compreensivelmente) percebe @skddc 's advocacia para RemoteStorage como shilling empurrando sua própria agenda, ao mesmo tempo @skddc é o primeiro neste segmento para apresentar um argumento decente para o protocolo que ele está propondo.

Talvez devêssemos apenas admitir que, mesmo depois de três anos em que esta edição foi aberta, simplesmente não existe um padrão para isso. O que nos deixa com três opções:

1. Aposte no remoteStorage, ainda não é um padrão
2. Use WebDAV de qualquer maneira, mas requer cabeçalhos CORS. Efetivamente, isso significa suporte apenas para NextCloud e ownCloud.
3. Escreva um plugin NextCloud customizado, com API customizada

Anúncio 1: remoteStorage como protocolo é muito bom, mas acho que a biblioteca cliente ainda não existe. Na verdade, a última experiência que tive com remoteStorage.js (a biblioteca cliente) não foi boa. Tudo meio que funcionou, mas ainda havia pequenos bugs em todos os lugares e eu simplesmente não considero a API de "modelagem de dados" de alto nível utilizável. A última parte não deve importar, visto que você pode simplesmente escrever seu próprio modelo de dados e ler e gravar arquivos brutos.

Anúncio 2: Isso funciona totalmente, mas agora você se limitou a NextCloud / ownCloud enquanto tem que lidar com a complexidade monstruosa do WebDAV. Acho que posso falar por todos que já trabalharam com esse protocolo quando digo que o uso do WebDAV apenas para usar um padrão não vale a pena se o usuário não se beneficiar dele.

Dado que Laverna já tem suporte para remoteStorage, suponho que investir mais tempo consertando a biblioteca cliente rs.js é uma boa maneira de avançar, embora provavelmente precisemos do suporte NextCloud para qualquer pessoa usar esse back-end. Um app especializado NextCloud também é uma boa opção IMO, embora isso perca o objetivo de ter um padrão ainda mais.

Olá,
Informe https://github.com/Laverna/laverna/issues/971#issuecomment -411423965 que explica o estado deste projeto.

Tenha um bom dia / noite,
Saúde,
Nissar