Laverna: 비상업적 저장소에 동기화

아니면 오운클라우드...

vol.cc를 보십시오. 그들은 파일에 물건을 저장하는 맞춤형 Go 기반 서버를 가지고 있습니다. 쉬운 로컬 저장을 위해 여기에 꽂을 수 있습니다.

예, owncloud에 연결하면 완벽합니다.

OwnCloud에 동기화하는 것은 흥미로울 것입니다.

Bittorrent Sync 옵션도 좋습니다.

자체 클라우드에 대한 +1

@michielbdejong이 StackEdit에 대해 썼듯이 , 내부에서 일반화된 다중 공급자 데이터 저장소 커넥터에 대한 흥미로운 접근 방식을 찾을 수 있습니다.

또한 이제 remoteStorage 도 구현 됩니다.

owncloud에 대한 +1!

+1

+1 Cozy.io, Owncloud, Bittorrent Sync. 그 중 하나는 훌륭할 것입니다!

이 스레드는 Laverna를 스토리지 제공업체에 연결하는 표준화된 방법의 필요성을 보여줍니다. 모든 사람은 개인 데이터를 호스팅하기 위해 선호하는 프로그램이 있습니다. 문제는 없지만 개발자가 실행 가능한 상용(Dropbox) 및 비상업(RemoteStorage) 수단을 제공했기 때문에 프로젝트의 다른 측면을 확장하는 데 중점을 두는 것이 좋습니다. 사용자에게 스스로 연결할 수 있는 도구를 제공하면 장기적으로 시간을 확보할 수 있습니다.

또한 Google 드라이브 동기화(또는 Google Keep 동기화)도 원합니다.

+1 - 저도 @andtheWings에 동의합니다.

그러나 현재로서는 GoogleDrive(대부분의 사람들이 이미 사용하고 있기 때문에 기본)와 OwnCloud(Dropbox 비상업적 대안으로 광범위하게 사용됨)의 2가지 서비스를 추가하면 매우 많은 사용자 기반을 포괄하고 더 많은 사람들에게 Laverna 메모를 공개할 것이라고 생각합니다.

이것은 커뮤니티를 실제로 확장할 수 있습니다.

remoteStorage는 Google Drive와 Dropbox 동기화를 기본 제공합니다. 5apps.com 에서 확인하세요.

_Edit:_ 브라우저의 Bittorrent Sync는 모험적인 것 같습니다.

@almereyda Err, remoteData를 통해 5apps.com을 사용하여 Google 드라이브에 내 메모를 저장하는 방법을 좀 더 구체적으로 말씀해 주시겠습니까?

@almereyda '즉시 사용 가능한 동기화'가 자신의 제어를 의미한다면 OwnCloud도 마찬가지입니다.

하지만 제 요점은 Laverna 사용법을 널리 알리고 일반 대중이 쉽게 사용할 수 있도록 하는 것입니다. Google 드라이브가 누락된 링크라고 생각합니다. 대부분의 사람들은 Google 계정을 가지고 있으며 다른 서비스 가입 및 설정으로 다시 시작하는 대신 Google 드라이브를 직접 사용할 수 있습니다.

여기 대부분의 사람들은 (저를 포함하여) OwnCloud를 선호하고 개방형/비상업적이기 때문에 Google 드라이브보다 먼저 개발되는 옵션을 확실히 추천합니다.

저는 Laverna가 Evernone을 대체할 수 있는 제품으로 발전할 수 있기를 바라면서 Laverna를 사용하기로 결정했습니다. 저는 Dropbox, Google Drive 등을 대체하기 위해 OwnCloud를 사용하고 있습니다. 더 이상 해당 서비스에 의존하지 않고 약관에 동의하지 않기 위해 이러한 조치를 취했습니다. Dropbox와 같은 서비스와 동기화할 수 있는 옵션을 추가하면 인기가 높아지겠지만(저는 권장합니다) 개인적으로는 적합하지 않습니다.

@SandeepPinge

만세!

대중을 위한 GDrive / 실제를 위한 Owncloud !
imho, Owncloud / GDrive는 우수한 무료/독점 소프트웨어 콤보를 만듭니다.

나는 내 자신의 웹 공간에서 Laverna를 실행하고 있습니다. 데이터(암호화)를 웹 서버에 직접 저장할 수 없는 이유는 무엇입니까? 아니면 내 웹 서버에 RemoteStorage를 구현할 수 있습니까? SSH 액세스 권한이 없습니다!

Laverna는 호스팅 응용 프로그램으로 생각되지 않았지만 파일을 로컬에 저장하여 로컬로 실행된다고 생각합니다. 장치 간 동기화를 훨씬 쉽게 하기 때문에 호스트 솔루션도 선호합니다.

현지의?
로컬 메모를 원하면 notepad.exe를 사용합니다.
;-)

Laverna는 호스팅되지 않도록 설계되었습니다. 즉, 기본적으로 데이터가 브라우저에 로컬로 저장됩니다. 추가 정보: https://unhosted.org/

"IndexedDB와 localStorage를 사용하기 때문에 우리 중 누구도 귀하의 개인 데이터에 액세스할 수 없습니다. 사실 귀하의 모든 정보는 클라이언트 측에만 저장됩니다."
즉, 데이터가 로컬로(브라우저에서 액세스할 수 있는 폴더에) 저장됩니다. 그러나 Dropbox(그리고 곧 다른 대안도 가능)를 사용하여 메모를 동기화할 수 있습니다.

여러분, 이제 Cozy Cloud에서 remoteStorage를 사용할 수 있으므로 자신의 인스턴스를 쉽게 회전할 수 있습니다.

또한 Laverna는 remoteStorage를 지원하지만 이미 오래된 사양 으로 보이기 때문에 ownCloud에 통합하는 작업도 진행 중입니다 .

@michielbdejong @skddc Laverna를 간단히 살펴보고 5apps와 동기화되지 않는 이유를 조사해 주시겠습니까? 0.10 릴리스 이전에는 작동했습니다. 그들은 클라이언트를 업데이트하지 않았습니까? submodule 하는 것이 의미가 있습니까?

나는 마리오네트나 이 앱의 소스 코드에 익숙하지 않습니다. 그러나 우리는 항상 일반적인 코드와 구체적인 코드에 대한 모든 질문과 도움과 답변을 제공합니다.

이 앱에서 RS 지원을 유지하는 사람(또는 일반적으로 앱을 유지 관리하는 사람): Freenode의 #remotestorage에서 당신을 환영하거나 포럼이나 GitHub에서 무엇에 대해 이야기하기를 매우 고대하고 있습니다.

Syncthing(https://syncthing.net/)과 Seafile(http://seafile.com/en/home/)도 추가하겠습니다.

1+ OwnCloud!

1+ 자체 클라우드

Owncloud는 훌륭할 것입니다.

자체 클라우드 +1

자체 클라우드 +1

자체 클라우드 +1
@Putdeksel과 정확히 같은 상황입니다.
자신의 저장 시스템을 사용하여 메모를 완전히 제어할 수 있다는 것은 놀라운 일이 될 것입니다.

자신의 저장 시스템을 사용하여 메모를 완전히 제어할 수 있다는 것은 놀라운 일이 될 것입니다.

네, 놀랍습니다. Laverna의 RemoteStorage 지원을 통해 이미 가능합니다. 단일 서버 구현에 얽매이지 않아도 RS 프로토콜을 사용하는 모든 서버에 메모를 저장할 수 있습니다. ;)

@skddc 솔직히 RemoteStorage를 살펴보지 않았습니다. 그러나 슬프게도 내가 볼 수있는 것은 내 공급자가 제공 한 서버에서 지원되지 않는 것 같습니다. 가까운 장래에 그렇게 되기를 바랍니다!

+1 ownCloud.

OwnCloud 동기화는 훌륭할 것입니다.

owncloud에 +1!

여기 있는 모든 ownCloud 사용자에게 제안할 사항이 있습니다.

ownCloud가 사용자별 데이터 저장을 위한 개방형 프로토콜을 지원한다면 앱 개발자(이 앱뿐만 아니라)가 ownCloud를 지원하는 것이 _훨씬_ 쉬울 것입니다. 이 앱은 이미 remoteStorage를 지원하므로 개발자가 앱에 특별한 ownCloud 지원을 추가하는 대신 ownCloud가 remoteStorage를 지원하는 경우 모든 remoteStorage 지원 앱은 자동으로 ownCloud가 원격 스토리지 서버 역할을 하도록 작동합니다.

따라서 ownCloud 자체에 대한 RS 지원을 요청/투표하거나 기여하면 좋을 것 같습니다!

이미 몇 년 동안 이 대화에 이어 두 번째로
@skddc 의 최근 발언.

2016년 7월 25일 14시 22분에 Sebastian Kippe [email protected] 은 다음과 같이 썼습니다.

여기 있는 모든 ownCloud 사용자에게 제안할 사항이 있습니다.

앱 개발자(이 앱뿐만 아니라)가 _훨씬_ 쉬울 것입니다.
ownCloud가 사용자별 개방형 프로토콜을 지원하는 경우 ownCloud를 지원합니다.
정보 저장소. 이 앱은 이미 remoteStorage를 지원하므로 ownCloud가
개발자가 특수 기능을 추가하는 대신 remoteStorage를 지원하기 위해
자신의 앱에 대해 ownCloud를 지원하면 모든 remoteStorage 지원 앱은
자동으로 원격 스토리지 서버 역할을 하는 ownCloud와도 작동합니다.

따라서 RS를 요청/투표하거나 기부해 주시면 좋을 것 같습니다.
ownCloud 자체 지원!

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/Laverna/laverna/issues/6#issuecomment -234938265 또는 음소거
스레드
https://github.com/notifications/unsubscribe-auth/ABka_MqpAc9pic432ehmtZ58HBUTh2Iyks5qZKqOgaJpZM4BqQ_m
.

이 문제를 +1 합니다!

흠, webDAV를 구현하기는 어렵지 않을까요? laverna를 수십 개의 다른 스토리지 제공업체에 연결할 수 있는 개방형 표준으로 볼 수 있기 때문인가요?

지정된 로컬 디렉토리에 데이터를 저장하지 않고 사람들이 Seafile 또는 ownCloud Desktop 클라이언트와 같은 동기화 클라이언트를 통해 데이터를 클라우드에 동기화할 수 있습니다.

지정된 로컬 디렉토리에 데이터를 저장하지 않고 사람들이 Seafile 또는 ownCloud Desktop 클라이언트와 같은 동기화 클라이언트를 통해 데이터를 클라우드에 동기화할 수 있습니다.

이는 앱의 잠재적 패키지 버전에서만 가능하지만 웹에서는 불가능합니다. 또한 remoteStorage가 해결하고 Laverna에서 사용되는 이유이기도 합니다.

지금까지 remoteStorage 통합에 대한 ownCloud 문제를 여는 사람이 있습니까? 나는 그것이 얼마나 훌륭하고 Laverna가 자동으로 ownCloud를 지원할 것이라는 점만 강조할 수 있습니다.

이는 앱의 잠재적 패키지 버전에서만 가능하지만 웹에서는 불가능합니다. 또한 remoteStorage가 해결하고 Laverna에서 사용되는 이유이기도 합니다.

나는 실제로 완전한 기능의 remoteStorage 동기화에 성공하지 못했습니다. 여러 번 시도했지만 매번 모든 사람을 상대하는 것은 다소 어렵습니다. IndexedDB 데이터가 마음에 들지 않습니다...

나는 DAV 동기화에 다소 익숙합니다. @wwebfor 는 오븐에서 동기화하는 또 다른 방법이 있다고 말했습니다.

나는 실제로 완전한 기능의 remoteStorage 동기화에 성공하지 못했습니다. 여러 번 시도했지만 매번 모든 사람을 상대하는 것은 다소 어렵습니다.

얼마 전에 동기화가 수정된 후 실패했다고 말하고 그것에 대해 문제를 제기했는데 결론이 나지 않았습니까?

그런 문제나 요청을 본 적이 없지만 기꺼이 도와드리겠습니다. "매번 모든 사람을 상대하기 어렵다"는 것이 무슨 뜻인지 잘 모르겠습니다.

IndexedDB 데이터에 익숙하지 않습니다.

음, 기본적으로 최신 브라우저에서 로컬로 사용할 수 있는 유일한 데이터베이스(물론 localStorage는 제외)이므로 다른 것을 사용할 수 있는 옵션은 없습니다.

얼마 전에 동기화가 수정된 후 실패했다고 말하고 그것에 대해 문제를 제기했는데 결론이 나지 않았습니까?

아니요, Gitter에 물었고 깨끗한 브라우저(Laverna를 사용한 적이 없는)에서 제대로 작동하는 것처럼 보이므로 사용한 모든 브라우저에서 모든 데이터를 정리해야 한다는 결론에 도달했습니다.

"매번 모든 사람을 상대하기 어렵다"는 것이 무슨 뜻인지 잘 모르겠습니다.

내가 사용하는 각 브라우저(또는 데스크톱 클라이언트) 중 하나를 사용할 때마다.

음, 기본적으로 최신 브라우저에서 로컬로 사용할 수 있는 유일한 데이터베이스(물론 localStorage는 제외)이므로 다른 것을 사용할 수 있는 옵션은 없습니다.

네, 알겠습니다. 그러나 나는 데이터를 동기화하는 이 방법에 익숙하지 않다는 것을 의미했습니다.

나에게 어떤 업그레이드 문제처럼 들린다. 그래서 쓰다보면...

나는 실제로 완전한 기능을 갖춘 remoteStorage 동기화에 성공하지 못했습니다.

... 그것은 여전히 ​​작동하지 않는다는 것을 의미합니까? 그렇다면 기꺼이 도와드리겠습니다.

webDAV의 경우 +1, "Owncloud only" 솔루션보다 훨씬 더 표준입니다. 열려있자 얘들아.

remoteStorage와 같은 무의미한 새로운 힙스터 솔루션을 통합하는 대신 검증된 webDav를 사용하는 것이 어떻습니까? 내 말은 요점이 무엇입니까? 업계 표준이 사실상 다른 것인데 왜 사용자가 당신의 의지에 굴복하도록 강요합니까?

예, rs는 이것을 지원하며 대부분의 사람들에게 거의 쓸모가 없습니다. 그러나 나는 신경쓰지 않는 또 다른 프로토콜을 사용하고 싶지 않습니다. 상용 Dropbox를 지원하지만 메모를 소유한다는 것은 메모를 타사 서버에 저장하고 싶지 않다는 의미입니다. 사람들이 소프트웨어의 친근함과 유연성 때문에 사용하기를 원할 때만 소프트웨어가 살아남을 수 있다는 것을 이해하고 싶지는 않습니다. 대신, 당신은 그들이 원하지 않는 일을 하도록 그들을 강력하게 무장시키는 것을 목표로 합니다. 이들은 모두 개발자와 기술에 정통한 사람들입니다. 당신은 이 간단한 사실을 이해하지 못합니다.

@technodrome 저는 Laverna 개발자를 말하는 것이 아니라 remoteStorage.js 개발자로서 말하는 것입니다. 내가 여기 있는 사람들을 도우려는 노력(나는 당신이 역사를 주의 깊게 읽어본다면 나는 다른 어떤 것도 시도하지 않았다)이 사람들에게 떠나라고 말하는 것과 같지 않다는 것은 분명하지 않을 것입니다. 왜냐하면 그들의 의견이 유효하지 않거나 다른 사람이 듣지 않기 때문입니다. 이것은 내가 볼 수있는 한 확실히 목소리를 낼 수있는 올바른 장소이며이 스레드의 첫 번째 의견이 왜 그렇게 적대적인지 잘 모르겠습니다. 이것은 우리 모두를 위한 무급 자원봉사이기 때문에 우리 모두 서로에게 친절합시다!

대신, 당신은 그들이 원하지 않는 일을 하도록 그들을 강하게 무장시키는 것을 목표로 삼습니다.

오픈 소스 소프트웨어를 무료로 제공하는 것이 누구에게나 큰 힘이 되는지 모르겠습니다. 이들이 모두 개발자와 기술에 정통한 사람들이라면 누군가 WebDAV 지원에 기여할 수 있습니까?

그럼 객관적으로 WebDAV의 실행 가능성을 살펴보자. 다음은 WebDAV를 통합하기 위해 해결해야 할 문제의 (아마도 불완전한) 목록입니다. (이것이 기본적으로 remoteStorage 프로토콜이 처음 생성된 바로 그 이유입니다. 사실 RS는 초기에 WebDAV를 사용하고 있었고 작성자는 실제 환경을 기반으로 더 간단한 REST API를 위해 이를 제거하기로 결정했습니다. 테스트 및 경험):

1. 코르스

브라우저가 작동하는 방식은 Laverna와 같은 호스팅되지 않은 앱이 JavaScript에서 서버에 직접 연결하는 것입니다. 여기에는 서버가 모든 요청에 ​​대해 Cross Origin Resource 헤더를 제공하고 데이터를 조작할 수 있는 POST, PUT, DELETE와 같은 HTTP 동사에 대한 OPTIONS 비행 전 요청을 지원해야 한다는 제한이 따릅니다. 대부분의 WebDAV 서버는 이것을 지원하지 않습니다. 따라서 많은 WebDAV 서버는 기본적으로 Laverna와 호환되지 않습니다.

문제: 해당 서버가 호환되지 않는 것에 대해 신경 쓰지 않더라도 앱이 지원 여부를 감지하는 방법은 무엇입니까? 이것은 실제로 브라우저가 연결 실패 이유에 대한 JS 코드 세부 정보를 의도적으로 제공하지 않기 때문에 훨씬 더 어려워지므로 일종의 검색 메커니즘이 필요합니다. 또한 정확한 원인이 무엇인지, 앱을 사용하기 위해 서버를 전환해야 할 수도 있다는 점을 사용자에게 설명해야 합니다.

RS의 솔루션: 프로토콜에는 CORS가 기본적으로 필요합니다. 또한 검색은 Webfinger를 통해 처리되며, 여기서 사용자 주소는 모든 구성 정보를 반환할 수 있을 뿐만 아니라 서버의 추가 기능을 발표할 수 있습니다.

일반 WebDAV/Laverna용 솔루션: 아이디어가 있습니까?

2. 권한/권한

권한은 프로토콜에 내장되어 있지 않기 때문에 WebDAV에서 서버 측 및 계정별로 처리되어야 합니다. 특정 폴더에 대한 액세스 권한이 존재하지 않습니다.

RS의 솔루션: OAuth 2.0을 사용하여 앱 개발자는 스토리지의 어느 부분에 액세스해야 하는지 결정할 수 있고 사용자는 어느 부분인지 쉽게 확인하고 간단한 대화 상자에서 액세스 권한 부여를 결정할 수 있습니다.

일반 WebDAV/Laverna에 대한 솔루션: 이것은 기본적으로 불가능하지만, 물론 해당 기능을 건너뛰고 Laverna에 모든 데이터에 대한 액세스 권한을 자발적으로 부여하는 것은 가능합니다. 우아하지는 않지만 확실히 구현을 위한 쇼스토퍼는 아닙니다.

3. 오프라인/모바일 지원

이것은 특히 WebDAV의 문제가 아니며 RS 사양만으로 완전히 해결됩니다. 그러나 모바일 지원 웹 앱의 경우에도 중요한 요소입니다. 데스크톱 및 모바일 연결은 모두 정기적으로 끊기며 이로 인해 메모가 저장되지 않는 것을 원하지 않을 것입니다. 따라서 일종의 오프라인 저장소를 사용해야 하고 원격 서버와 지능적으로 동기화해야 합니다(물론 좋은 사용자 경험을 만들고 싶다면 매번 드롭할 때마다 재인증 없이).

여기에는 두 가지 문제가 있습니다.

문제 1: 서버는 Etags를 지원해야 하므로 먼저 동기화 메커니즘을 구축할 수 있습니다.

RS의 솔루션: 이것은 단일 문서 자체뿐만 아니라 디렉토리 리소스와 항목 목록 모두에 ETag를 요구함으로써 프로토콜에서 부분적으로 해결됩니다. 이를 기반으로 If-None-Match 와 같은 HTTP 헤더를 사용하여 동기화 메커니즘을 구축할 수 있고 변경되지 않은 것을 요청하는 경우에는 empty 304 412 , 거부하는 경우에는

일반 WebDAV/Laverna를 위한 솔루션: 불행히도 Etag 지원은 WebDAV 사양에서 SHOULD일 뿐이므로 많은 서버에서 지원하지 않으며 일부는 구현되어 있기 때문에 지원을 지원하더라도 사용자에게 명시적으로 지원을 끄도록 요청합니다. 비효율적인 방식으로. (사실 이것은 서버 개발자에게 쉬운 문제가 아닙니다. 제가 확실히 증명할 수 있습니다.) 그러나 CORS와 유사하게 가능합니다. 따라서 여기에서 솔루션은 다시 기능 검색과 사용자에게 서버를 구성하도록 안내하거나 다른 서버로 전환해야 한다고 알려주는 것입니다. 다행히도 응답 헤더를 검사하여 JS에서 이를 감지할 수 있기 때문에 CORS보다 훨씬 쉽습니다.

문제 2: 실제 동기화 메커니즘을 작성하거나 하나를 제공하는 라이브러리 사용

RS의 솔루션: 아주 초기에 사양 작성자 중 한 명이 RS를 앱에 통합하려는 사람들을 위해 이 문제를 해결하기 위해 참조 클라이언트 라이브러리를 만들기 시작했습니다. 그것은 여전히 ​​유지 및 개발 중이며 수십만 개의 서로 다른 연결, 장치, OS, 브라우저, Cordova 등에서 전투 테스트를 거쳤습니다. Laverna에서도 사용되고 있습니다. 첫 번째 커밋은 2010년 11월로 거슬러 올라가므로 "새로운 힙스터 솔루션"이 아닙니다. 버그가 있는 경우 기꺼이 도와주는 사람들이 있으며 피드백은 항상 감사하고 있습니다.

일반 WebDAV/Laverna용 솔루션: 가능한 솔루션 중 하나는 사용자 지정 수동 라이브러리입니다. 그러한 코드를 생성, 수정 및 유지하려는 노력은 내가 나열한 다른 문제를 확실히 축소시킬 것이지만, 물론 가능한 일입니다. 문자 그대로 구현해야 할 다른 수천 가지를 제외하고 내가 가정하는 주요 과제는 아마도 결국 WebDAV 서버의 다양한 동작일 것입니다. 그들의 Etag 구현. 하지만 그런 라이브러리를 알고 계시다면(아무것도 모르고 지금 다시 확인해보니 저도 찾을 수 없었습니다) 다른 미해결 문제들을 어떤 식으로든 해결하고 WebDAV를 기술 사용자.

이 목록에 포함된 오류나 잘못된 사실을 용서하고 지적해 주십시오. 나는 기본적으로 머리 꼭대기에서 모든 것을 썼습니다. 조만간 이것을 RS 위키로 옮기고 내가 작성한 내용을 검토/편집하도록 일부 사람들에게 요청할 것입니다. 이것이 실제로 WebDAV와 RS의 차이점에 대한 다소 유용한 설명이고 RS가 WebDAV가 해결하는 문제를 해결하는 방법이라고 생각하기 때문입니다. 브라우저에서 완전히 실행되는 클라이언트 측 웹 앱의 경우에는 그렇지 않습니다(당시에는 웹 플랫폼 기능이 실제로 존재하지 않았고 오프라인 우선 웹 앱의 전체 개념이 물건).

@technodrome WebDAV 지원을 받는 목표를 진행하려면 이러한 문제(또는 완전히 무효화하는 사실)에 대한 잠재적 솔루션을 지적하는 것이 큰 도움이 될 것입니다.

죄송합니다만 상식적인 사용자 관점이 본인의 감정이나 의견을 상하게 하는 것 같아서 이해하지 못한다면 문제는 본인에게 있습니다. 사람들을 위한 소프트웨어는 정의상 당신뿐만 아니라 여러 사람이 사용합니다. 따라서 브레인스토밍과 아이디어가 프로젝트를 추진하는 것이기 때문에 모든 사람이 의견을 제시하도록 초대되어야 합니다. 그리고 webDav 또는 기타 표준화된 프로토콜 지원에 대해 +1을 발행하는 사람들로 판단하면 저만 그런 것은 아닙니다.

일반적인 차원에서 개인적인 의견이었음에도 불구하고 제가 한 말을 왜곡하고 개인적으로 받아들이려 하고 있습니다. 하지만 요점은 - 개발자가 사용자 데이터를 저장하는 표준화된 방법을 제공하지 않는다면 그렇습니다 - 개발자는 사용자가 개발자의 선호도를 사용하도록 강력하게 무장하고 있습니다.

기술에 정통한 사용자는 프로그래머와 같지 않습니다. 당신의 수사에 적합하다는 이유로 성급하게 결론을 내리지 마십시오.

그리고 그 노고와 노력에 감사하다고 분명히 말했고 진심으로 감사합니다. 단지 당신이 그렇게 말했다고 해서 내가 맹목적으로 모든 것에 동의한다는 의미는 아닙니다. 그것은 당신의 권리이며 이 문제를 해결하는 방법은 백만 가지가 있습니다. 물론 당신은 당신의 제품을 밀어붙이고 있지만 여기에서 조금 민주적으로 당신뿐만 아니라 더 많은 사람들에게 적합한 선택의 자유를 제공합시다.

작동할 수 없는 이유와 RS 솔루션이 모든 고통에 대한 치료법인 이유를 나열했지만, 로컬 데몬(클라이언트, 서버)으로 실행되는 중간 엔드포인트(Go 앱?)가 권한 부여를 처리할 수 있다고 확신합니다. 원하는 모든 프로토콜을 통합할 수 있는 가능성의 호스트를 활성화합니다. 2년 안에 잊혀지고 쓸모가 없어질 수도 있는 전체 기술 스택을 유지하는 것보다 확실히 덜 골칫거리입니다.

또한 내 의견은 누구의 잘못을 증명하기 위한 것이 아니라 특정 산업 표준이 있고 그러한 표준이 되는 데에는 이유가 있다는 것입니다. 당신이 그것을 이해할 수 없다면, 당신의 것 이외의 다른 진실을 당신에게 확신시킬 수 있는 논증은 없을 것입니다.

글쎄, 나는 양쪽의 좋은 주장을 읽었습니다. 결국 내 스토리지를 소유하는 것이 나에게 요구 사항이었고 서버의 (암호화 된) 스토리지가 프로젝트 핵심의 일부이기 때문에 turtl에갔습니다.
앞에서 언급했듯이 제품이 모든 요구 사항에 적합하지 않고 그 이유가 있는 것 같으면(물론 여전히 논쟁할 수 있음) 필요와 요구 사항에 더 가까운 것을 찾으십시오.
많은 사람들이 Dropbox에 파일을 호스팅하는 데 문제가 없을 것입니다. 특히 오픈 소스 제품에서 모든 작업을 수행할 필요가 없습니다. 좌절감을 이해하고 공유하지만 오픈 소스에는 많은 비즈니스 계획이 있으며 때로는 요구 사항을 충족하지 않습니다. 그냥 처리해야합니다.

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

죄송하지만 상식적인 사용자 관점을 이해하지 못하신다면
당신의 감정이나 의견이 상처를 받는다고 느끼기 때문에 문제가
당신과 함께 있습니다. 사람들을 위한 소프트웨어는 정의에 의해 사용됩니다.
한 명 이상 - 당신뿐만 아니라. 이와 같이 모든 사람은 다음과 같아야 합니다.
브레인스토밍과 아이디어가 중요하기 때문에 의견을 제안하도록 초대되었습니다.
프로젝트를 추진합니다. 에 대해 +1을 발행한 사람들로 판단하면
webDav 또는 기타 표준화된 프로토콜 지원, 그것은 나만이 아닙니다.

내가 한 말을 왜곡하고 인신공격까지 하려 하네
비록 그것들은 일반적인 수준에서 개인적인 의견을 의미했지만. 하지만
요점 - 개발자가 표준화된 방법을 제공하지 않는 경우
사용자 데이터를 저장한 다음 예 - 사용자가
개발자의 환경 설정을 사용하십시오.

기술에 정통한 사용자는 프로그래머와 같지 않습니다. 성급하게 결론을 내리지 마십시오
그것은 당신의 수사학에 적합하기 때문입니다.

그리고 그 노고와 노력에 감사하다고 분명히 말했고 진심으로 감사합니다.
그냥 맹목적으로 모든 것에 동의한다는 의미는 아닙니다.
당신은 그렇게 말했다. 그것은 당신의 권리이며 백만 가지 방법이 있습니다.
이 문제를 해결하는 방법. 물론 당신은 당신의
제품이지만 여기에서는 약간 민주적이며 자유를 제공합니다.
당신뿐만 아니라 더 많은 사람들에게 적합한 선택.

작동할 수 없는 이유와 귀하의
RS 솔루션은 모든 고통의 치료제입니다. 저는 확신합니다.
로컬 데몬(클라이언트, 서버)으로 실행되는 엔드포인트(Go 앱?)는
권한을 관리하고 많은 가능성을 가능하게 합니다.
원하는 거의 모든 프로토콜을 통합합니다. 확실히 덜 가져온다
전체 기술 스택을 유지하는 것보다 골칫거리
2년 안에 잊혀지지 않고 쓸모없게 될 것입니다.

또한 내 의견은 누군가가 틀렸다는 것을 증명하기 위한 것이 아닙니다.
특정 산업 표준이 있고 일을 하는 데에는 이유가 있습니다.
그런 기준이 됩니다. 당신이 그것을 이해할 수 없다면, 나는 두려워요
다른 진실을 확신시킬 수 있는 논증은 없습니다
당신보다.

--
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/Laverna/laverna/issues/6#issuecomment -282279742

--
Envoyé de mon appareil Android avec K-9 Mail. 뵈이레즈 핑서 마 브리에베테.

따라서 브레인스토밍과 아이디어가 프로젝트를 추진하는 것이기 때문에 모든 사람이 의견을 제시하도록 초대되어야 합니다. 그리고 webDav 또는 기타 표준화된 프로토콜 지원에 대해 +1을 발행하는 사람들로 판단하면 저만 그런 것은 아닙니다.

예! 나는 그것을 정확히 말한 다음 당신의 소원을 이루기 위해 해결해야한다고 생각하는 것을 지적하기 위해 시간과 노력을 기울였습니다. 나는 "내 의제"에 맞추기 위해 어떤 것도 왜곡하지 않았으며, 귀하와 다른 사람이 내 객관적인 분석에 포함된 오류를 지적하도록 적극적으로 초대하고 귀하 자신의 선호도/아이디어의 구현을 진행하는 데 도움을 주기도 했습니다.

유감스럽게도 귀하의 후속 댓글에서 제기된 비난 중에서 실질적인 주장이나 새로운 사실을 찾기가 쉽지 않습니다. 그러나 한 단락에는 최소한 다음과 같은 아이디어가 포함되어 있습니다.

로컬 데몬(클라이언트, 서버)으로 실행되는 중간 끝점(Go 앱?)이 권한 부여를 처리하고 원하는 모든 프로토콜을 통합할 수 있는 가능성의 호스트를 활성화할 수 있다고 확신합니다.

네, 물론 이론상으로는 가능합니다. 그것의 문제는 그것이 바로 같은 단락에서 당신 자신의 의견 및 주장과 완전히 충돌한다는 것입니다.

2년 안에 잊혀지고 쓸모가 없어질 수도 있는 전체 기술 스택을 유지하는 것보다 확실히 덜 골칫거리입니다.

귀하의 아이디어는 웹 앱이 원격으로 데이터를 저장하고 장치 간에 동기화할 수 있도록 완전히 새로운 기술 스택("클라이언트, 서버")을 생성, 테스트 및 유지 관리하는 것을 정확히 의미합니다. 이 완전히 새로운 스택을 발명하고 유지 관리하는 문제 외에도 모든 장치, 가장 중요한 모바일 장치에서 해당 로컬 프로그램을 실행하는 것은 다소 어려울 것입니다.

또한 내 의견은 누구의 잘못을 증명하기 위한 것이 아니라 특정 산업 표준이 있고 그러한 표준이 되는 데에는 이유가 있다는 것입니다.

나는 그것에 완전히 동의합니다! 그리고 WebDAV가 실제로 클라이언트 측 웹 앱에 대한 표준이 되지 않은 이유와 RS 프로토콜이 처음에는 WebDAV를 API로 사용하여 사용자별, 자체 호스팅을 만들기 위한 새로운 표준으로 생성된 이유를 자세히 설명했습니다. 이 정확한 유형의 애플리케이션에 대해 가능한 스토리지.

실제로는 다소 단순한 프로토콜이며 "기술 스택"의 반대입니다. 해당 부분에 대한 빠른 설명을 보지 못한 경우 이 웹 사이트에서 찾을 수 있습니다. -- 또한 ​​"webDav 또는 기타 표준화된 프로토콜 지원"과 관련 하여 RS가 의미하는 바는 바로 .

이제 WebDAV가 클라이언트 측 웹 앱에 대해 지나치게 실행 가능한 솔루션이 아니라는 점에 대해 부정적으로 느낄 수도 있지만, 그렇다고 해서 당면한 사실이 바뀌거나 그런 사실을 지적하는 저를 이기적인 바보로 만들지는 않습니다. 제발, 제발 이 문제를 합리적으로 논의하고 개인적인 비난은 아닙니다 . 누군가가 같은 목표를 달성하는 다른 솔루션을 생각해 낼 수 있다면 개인 취향이나 이념에 따라 반대하는 사람은 제가 마지막입니다.

웹 응용 프로그램인 Laverna는 전송 프로토콜로 HTTP만 지원할 수 있으며 작동하려면 CORS가 필요합니다. 그러나 어떤 이유로 사람들은 BitTorrent Sync 또는 WebDAV와 같은 것을 제안하고 있습니다. 그 중 하나는 HTTP를 통해 실행되지 않고 둘 다 사양의 일부로 CORS가 없습니다. 사실 전자는 사양도 없고 독점 프로토콜입니다. @technodrome 은 WebDAV의 사용을 "상식적인 사용자 관점"이라고 부르기까지 합니다. 그러나 브라우저 내 Javascript 애플리케이션에서 WebDAV를 사용하는 것은 일반적인 경우에 작동하지 않으므로 관점에 관계없이 의미가 없습니다. . 중간 프록시를 사용하여 CORS 헤더를 추가하는 것에 대한 이야기도 좋은 UX에 대한 제 생각과 일치하지 않습니다.

나는 이것이 실제로 이 토론이 "일반적인 소프트웨어 자유"를 원하고 일부 확립된 프로토콜의 이름을 버리는 사람들에 의해 대부분 지배되고 있음을 실제로 보여줍니다. 기술적인 관점에서 이러한 옵션 중 하나를 실제로 진지하게 조사하고 작업에 적합한 도구입니다. 다시 한 번 @technodrome 을 부르고 싶습니다. 그는 또한 @skddc가 remoteStorage에 대한 옹호를 자신의 의제를 밀어붙이는 실링 으로 인식하기 때문에 (이해할 수 있음), 동시에 @skddc 가 이 스레드의 첫 번째 사람입니다. 그가 제안하는 프로토콜에 대한 적절한 주장을 하기 위해.

아마도 우리는 이 문제가 공개된 지 3년이 지난 후에도 이에 대한 표준이 없다는 것을 인정해야 할 것입니다. 세 가지 옵션이 있습니다.

1. 아직 표준이 아닌 remoteStorage에 베팅
2. 어쨌든 WebDAV를 사용하지만 CORS 헤더가 필요합니다. 사실상 이것은 NextCloud 및 ownCloud에 대한 지원만 의미합니다.
3. 사용자 정의 API를 사용하여 사용자 정의 NextCloud 플러그인 작성

광고 1: 프로토콜로서의 remoteStorage는 꽤 좋은데 클라이언트 라이브러리가 아직 거기에 있다고 생각하지 않습니다. 사실 remoteStorage.js(클라이언트 라이브러리)에 대한 마지막 경험은 좋지 않았습니다. 모든 것이 제대로 작동했지만 여전히 사소한 버그가 곳곳에 있었고 저는 상위 수준의 "데이터 모델링" API를 사용할 수 있다고 생각하지 않습니다. 자신의 데이터 모델을 작성하고 원시 파일을 읽고 쓸 수 있다는 점을 감안하면 마지막 부분은 중요하지 않습니다.

Ad 2: 이것은 완전히 작동하지만 이제 WebDAV의 엄청난 복잡성을 처리해야 하는 동안 NextCloud/ownCloud로 제한되었습니다. 표준을 사용하기 위해 WebDAV를 사용하는 것은 사용자가 혜택을 받지 못한다면 가치가 없다고 말할 때 해당 프로토콜을 사용해 본 모든 사람을 대변할 수 있다고 생각합니다.

Laverna가 이미 remoteStorage를 지원한다는 점을 감안할 때 rs.js 클라이언트 라이브러리를 수정하는 데 더 많은 시간을 투자하는 것이 앞으로 나아가는 좋은 방법이라고 생각합니다. 하지만 누군가가 해당 백엔드를 사용하려면 NextCloud 지원이 필요할 수 있습니다. 전문화된 NextCloud 앱도 좋은 옵션 IMO이지만 표준을 훨씬 더 많이 확보하려는 목표를 놓치고 있습니다.

안녕하세요,
이 프로젝트의 상태를 설명하는 https://github.com/Laverna/laverna/issues/971#issuecomment -411423965로 보고하세요.

좋은 낮/밤 되세요.
건배,
니사르