Laverna: Sinkronkan ke penyimpanan non-komersial

Atau Owncloud...

Lihat vole.cc. Mereka memiliki server berbasis Go khusus yang menyimpan barang ke file. Anda mungkin bisa mencolokkan ini untuk penyimpanan lokal yang mudah.

Ya pasang ke owncloud akan sempurna

Menyinkronkan ke OwnCloud akan menarik.

Opsi Sinkronisasi Bittorrent juga bagus.

+1 untuk owncloud

Seperti yang ditulis @michielbdejong tentang StackEdit , di dalamnya orang mungkin menemukan pendekatan menarik untuk konektor penyimpanan data multi-penyedia umum.

Juga, remoteStorage sekarang diimplementasikan juga.

+1 untuk owncloud!

+1

+1 Cozy.io, Owncloud, Sinkronisasi Bittorrent. Salah satu dari itu akan sangat bagus!

Saya pikir utas ini menunjukkan perlunya metode standar yang menghubungkan Laverna ke penyedia penyimpanan. Setiap orang memiliki program pilihan mereka sendiri untuk meng-hosting data pribadi. Tidak ada yang salah dengan itu, tetapi sekarang para pengembang telah menyediakan sarana komersial (Dropbox) dan non-komersial (RemoteStorage) yang layak untuk melakukannya, saya lebih suka mereka fokus pada perluasan aspek lain dari proyek. Memberi pengguna alat untuk terhubung sendiri akan membebaskan waktu dalam jangka panjang.

Saya juga ingin sinkronisasi Google Drive (atau bahkan sinkronisasi Google Keep)

+1 - Saya juga setuju dengan @andtheWings.

Tetapi untuk saat ini saya pikir menambahkan 2 layanan: GoogleDrive (utama, karena kebanyakan orang sudah menggunakannya) dan OwnCloud (alternatif non-komersial Dropbox yang banyak digunakan) akan mencakup basis pengguna yang sangat besar dan membuka catatan Laverna untuk lebih banyak orang.

Ini benar-benar dapat memperluas komunitas.

Harap perhatikan remoteStorage membawa sinkronisasi Google Drive dan Dropbox di luar kotak. Cek di 5apps.com .

_Edit:_ Bittorrent Sync di browser terdengar menantang.

@almereyda Err, bisakah Anda lebih spesifik bagaimana saya bisa menyimpan catatan saya melalui remoteData ke google drive dengan 5apps.com?

@almereyda Jika dengan 'out-of-the-box sync', maksud Anda dalam kendali Anda sendiri, maka begitu juga OwnCloud.

Tapi maksud saya adalah untuk menyebarkan penggunaan Laverna dan membuatnya mudah diadopsi oleh masyarakat umum. Saya percaya Google Drive adalah tautan yang hilang di sana. Kebanyakan orang memiliki akun Google dan mereka dapat langsung menggunakan Google Drive mereka vs memulai ulang dengan pendaftaran dan penyiapan layanan lain.

Karena kebanyakan orang di sini lebih suka OwnCloud (termasuk saya) dan terbuka/non-komersial, saya pasti akan merekomendasikan opsi yang dikembangkan terlebih dahulu melalui Google Drive.

Saya memilih untuk menggunakan Laverna, berharap itu bisa berkembang menjadi sesuatu yang bisa menggantikan Evernone. Saya menggunakan OwnCloud untuk menggantikan Dropbox, Google Drive dll. Saya mengambil langkah-langkah ini sehingga saya tidak lagi harus bergantung pada layanan tersebut dan menyetujui persyaratan mereka. Saya mendapatkan bahwa menambahkan opsi untuk menyinkronkan dengan layanan seperti Dropbox akan menambah popularitas (dan saya mendorong itu), tetapi bagi saya pribadi itu tidak cocok.

@SandeepPinge

Hore!

GDrive untuk massa / Owncloud untuk yang asli!
imho, Owncloud / GDrive membuat kombo perangkat lunak gratis / berpemilik yang sangat baik.

Saya menjalankan Laverna di ruang web saya sendiri. Mengapa saya tidak dapat menyimpan data (terenkripsi) langsung ke server web? Atau bisakah saya mengimplementasikan RemoteStorage di server web saya? Saya tidak memiliki akses SSH!

Saya pikir Laverna tidak dianggap sebagai aplikasi yang dihosting, tetapi berjalan lokal dengan menyimpan file secara lokal. Saya lebih suka solusi yang dihosting juga, karena ini membuat sinkronisasi antar perangkat menjadi lebih mudah.

Lokal?
Jika saya ingin catatan lokal saya menggunakan notepad.exe.
;-)

Laverna dirancang untuk tidak dihosting, yaitu agar data disimpan secara lokal di browser secara default. Info lebih lanjut di sini: https://unhosted.org/

"Tidak seorang pun dari kami yang dapat mengakses data pribadi Anda karena kami menggunakan IndexedDB dan Penyimpanan lokal. Faktanya, semua informasi Anda hanya akan disimpan di sisi klien."
Artinya, afaik bahwa data disimpan secara lokal (dalam folder yang dapat diakses oleh browser). Tetapi orang dapat menggunakan Dropbox (dan semoga alternatif lain segera) untuk menyinkronkan catatan.

Semuanya, harap perhatikan bahwa remoteStorage sekarang tersedia di Cozy Cloud , sehingga Anda dapat dengan mudah memutar instance Anda sendiri.

Selain itu, karena Laverna mendukung remoteStorage, tetapi tampaknya merupakan spesifikasi lama, ada pekerjaan yang sedang dilakukan untuk mengintegrasikannya ke ownCloud juga.

@michielbdejong @skddc Bisakah Anda melihat sekilas Laverna dan memeriksa mengapa gagal disinkronkan dengan 5apps? Dulu berfungsi, saya percaya sebelum rilis 0,10. Apakah mereka tidak memperbarui klien? Apakah masuk akal untuk submodule itu?

Saya tidak akrab dengan Marionette atau kode sumber aplikasi ini. Namun, kami selalu di sini untuk membantu dan menjawab dan semua pertanyaan, baik yang umum maupun untuk kode konkret.

Siapa pun yang memelihara dukungan RS di aplikasi ini (atau mengelola aplikasi secara umum): kami sangat menantikan untuk menyambut Anda di #remotestorage di Freenode atau mengobrol tentang apa pun di forum atau GitHub.

Saya akan menambahkan Syncthing (https://syncthing.net/) dan Seafile (http://seafile.com/en/home/) juga.

1+ untuk OwnCloud!

1+ OwnCloud

Owncloud akan sangat bagus.

Owncloud +1

owncloud +1

owncloud +1
Saya dalam situasi yang sama persis dengan @Putdeksel
Menjadi benar-benar mengendalikan catatan Anda dengan menggunakan sistem penyimpanan Anda sendiri akan luar biasa.

Menjadi benar-benar mengendalikan catatan Anda dengan menggunakan sistem penyimpanan Anda sendiri akan luar biasa.

Ya, itu _is_ menakjubkan dan sudah dimungkinkan melalui dukungan RemoteStorage Laverna. Anda bahkan tidak terikat pada implementasi server tunggal, tetapi server mana pun yang menggunakan protokol RS dapat menyimpan catatan Anda. ;)

@skddc saya belum melihat ke RemoteStorage jujur. Tapi sayangnya dari apa yang saya lihat sepertinya tidak didukung di server yang saya miliki dari penyedia saya. Semoga dalam waktu terdekat!

+1 sendiriCloud.

Sinkronisasi OwnCloud akan sangat bagus.

+1 untuk owncloud!

Bolehkah saya menyarankan sesuatu untuk semua pengguna ownCloud di sini:

Akan _jauh_ lebih mudah bagi pengembang aplikasi (bukan hanya aplikasi ini) untuk mendukung ownCloud, jika ownCloud mendukung protokol terbuka untuk penyimpanan data per pengguna. Aplikasi ini sudah mendukung remoteStorage, jadi jika ownCloud mendukung remoteStorage, alih-alih pengembang harus menambahkan dukungan ownCloud khusus ke aplikasi mereka, maka semua aplikasi yang mendukung remoteStorage secara otomatis juga akan bekerja dengan ownCloud yang bertindak sebagai server penyimpanan jarak jauh.

Oleh karena itu, saya pikir akan sangat bagus jika Anda meminta/memilih, atau menyumbangkan dukungan RS untuk ownCloud itu sendiri!

Mengikuti percakapan ini selama beberapa tahun, saya harus kedua
@skddc komentar terbaru.

Pada 25 Juli 2016 pukul 14:22, Sebastian Kippe [email protected] menulis:

Bolehkah saya menyarankan sesuatu untuk semua pengguna ownCloud di sini:

Akan _jauh_ lebih mudah bagi pengembang aplikasi (bukan hanya aplikasi ini) untuk
mendukung ownCloud, jika ownCloud mendukung protokol terbuka untuk per-pengguna
penyimpanan data. Aplikasi ini sudah mendukung penyimpanan jarak jauh, jadi jika ownCloud adalah
untuk mendukung penyimpanan jarak jauh, alih-alih pengembang harus menambahkan khusus
memiliki dukungan ownCloud ke aplikasi mereka, maka semua aplikasi yang mendukung Penyimpanan jarak jauh akan
secara otomatis juga bekerja dengan ownCloud yang bertindak sebagai server penyimpanan jarak jauh.

Oleh karena itu, saya pikir akan sangat bagus jika Anda meminta/memilih, atau berkontribusi RS
dukungan untuk ownCloud itu sendiri!

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/Laverna/laverna/issues/6#issuecomment -234938265, atau bisukan
benang
https://github.com/notifications/unsubscribe-auth/ABka_MqpAc9pic432ehmtZ58HBUth2Iyks5qZKqOgaJpZM4BqQ_m
.

Saya +1 masalah ini!

Hmm apakah akan sulit untuk mengimplementasikan webDAV karena ini dapat dilihat sebagai standar terbuka yang memungkinkan laverna terhubung ke lusinan penyedia penyimpanan yang berbeda?

Mengapa tidak menyimpan data dalam direktori lokal tertentu dan orang-orang dapat menyinkronkan data mereka ke cloud melalui klien sinkronisasi seperti klien Seafile atau ownCloud Desktop?

Mengapa tidak menyimpan data dalam direktori lokal tertentu dan orang-orang dapat menyinkronkan data mereka ke cloud melalui klien sinkronisasi seperti klien Seafile atau ownCloud Desktop?

Itu hanya mungkin dalam versi paket aplikasi yang potensial, tetapi tidak di Web. Itu juga yang dipecahkan oleh remoteStorage dan mengapa digunakan di Laverna.

Apakah ada orang di sini yang membuka masalah ownCloud tentang mengintegrasikan remoteStorage sejauh ini? Saya hanya bisa menekankan betapa hebatnya itu dan bahwa Laverna kemudian akan secara otomatis mendukung ownCloud.

Itu hanya mungkin dalam versi paket aplikasi yang potensial, tetapi tidak di Web. Itu juga yang dipecahkan oleh remoteStorage dan mengapa digunakan di Laverna.

Saya sebenarnya tidak pernah berhasil memiliki sinkronisasi remoteStorage yang berfungsi penuh. Saya mencoba berkali-kali, dan agak sulit untuk berurusan dengan semua orang setiap saat. Saya tidak begitu nyaman dengan data IndexedDB ...

Saya agak akrab dengan sinkronisasi DAV. @wwebfor memberi tahu saya ada cara lain untuk menyinkronkan di oven, pikir.

Saya sebenarnya tidak pernah berhasil memiliki sinkronisasi remoteStorage yang berfungsi penuh. Saya mencoba berkali-kali, dan agak sulit untuk berurusan dengan semua orang setiap saat.

Apakah Anda mengatakan itu gagal setelah sinkronisasi diperbaiki beberapa waktu lalu, dan Anda membuka masalah tentang itu, yang tidak sampai pada kesimpulan?

Saya belum pernah melihat masalah atau permintaan seperti itu, tetapi saya akan dengan senang hati membantu Anda! Tidak yakin apa artinya "sulit untuk berurusan dengan semua orang setiap saat".

Saya tidak begitu nyaman dengan data IndexedDB

Yah, pada dasarnya ini adalah satu-satunya database yang tersedia secara lokal di browser modern (kecuali untuk localStorage tentu saja), jadi sebenarnya tidak ada pilihan untuk menggunakan sesuatu yang lain.

Apakah Anda mengatakan itu gagal setelah sinkronisasi diperbaiki beberapa waktu lalu, dan Anda membuka masalah tentang itu, yang tidak sampai pada kesimpulan?

Tidak, saya bertanya di Gitter, dan saya sampai pada kesimpulan bahwa saya harus membersihkan semua data saya di setiap browser yang saya gunakan karena tampaknya berfungsi dengan baik di browser yang bersih (di mana Laverna tidak pernah digunakan).

Tidak yakin apa artinya "sulit untuk berurusan dengan semua orang setiap saat".

Setiap browser (atau klien desktop) yang saya gunakan, setiap kali saya menggunakan salah satunya.

Yah, pada dasarnya ini adalah satu-satunya database yang tersedia secara lokal di browser modern (kecuali untuk localStorage tentu saja), jadi sebenarnya tidak ada pilihan untuk menggunakan sesuatu yang lain.

Ya, ya, saya mengerti. Tapi maksud saya saya tidak terbiasa dengan cara menyinkronkan data ini.

Kedengarannya seperti beberapa masalah peningkatan bagi saya. Jadi, ketika Anda menulis ...

Saya sebenarnya tidak pernah berhasil memiliki sinkronisasi penyimpanan jarak jauh yang berfungsi penuh

... apakah itu berarti masih tidak berhasil? Jika itu masalahnya, maka saya akan tetap dengan senang hati membantu.

+1 untuk webDAV, jauh lebih standar daripada solusi "Owncloud saja". Ayo tetap Terbuka guys.

Alih-alih mengintegrasikan banyak solusi hipster baru yang tidak masuk akal seperti remoteStorage, mengapa tidak menggunakan webDav yang telah dicoba dan diuji? Maksudku apa gunanya? Mengapa Anda memaksa pengguna untuk tunduk pada keinginan Anda jika standar industri secara de facto adalah sesuatu yang lain?

Mengatakan ya, rs mendukung ini dan itu tidak banyak berguna bagi kebanyakan orang. Tetapi saya tidak ingin menggunakan protokol lain yang tidak saya pedulikan. Anda mendukung Dropbox komersial, tetapi MEMILIKI catatan berarti saya tidak ingin menyimpannya ke server pihak ketiga. Anda hanya tidak ingin memahami perangkat lunak Anda akan bertahan hanya jika orang ingin menggunakannya karena keramahan dan fleksibilitasnya. Sebaliknya, Anda bertujuan untuk mempersenjatai mereka dengan kuat menjadi sesuatu yang tidak ingin mereka lakukan. Ini semua adalah pengembang dan orang yang paham teknologi, Anda hanya tidak mendapatkan fakta sederhana ini.

@technodrome Saya tidak berbicara untuk pengembang Laverna, tetapi sebagai pengembang remoteStorage.js. Mungkin tidak jelas, bahwa usaha saya membantu orang di sini (saya tidak pernah mencoba yang lain, jika Anda membaca sejarah dengan cermat) tidak sama dengan menyuruh orang pergi, karena pendapat mereka tidak valid atau didengar oleh orang lain. Ini tentu saja tempat yang tepat untuk menyuarakan mereka sejauh yang saya bisa lihat, dan saya tidak yakin mengapa komentar pertama Anda di utas ini begitu bermusuhan. Mari kita semua bersikap baik satu sama lain, karena ini adalah kerja sukarela yang tidak dibayar untuk kita semua!

Sebaliknya, Anda bertujuan untuk mempersenjatai mereka dengan kuat menjadi sesuatu yang tidak ingin mereka lakukan

Saya tidak melihat bagaimana menyediakan perangkat lunak sumber terbuka, gratis, mempersenjatai siapa pun. Jika ini semua adalah pengembang dan orang-orang yang paham teknologi, pasti seseorang dapat menyumbangkan dukungan WebDAV, apakah itu masuk akal?

Jadi, mari kita lihat kelayakan WebDAV secara objektif. Berikut adalah daftar (mungkin tidak lengkap) dari masalah yang dapat saya pikirkan, yang perlu dipecahkan agar WebDAV dapat diintegrasikan. (Ini pada dasarnya adalah alasan utama mengapa protokol remoteStorage dibuat. Faktanya, RS menggunakan WebDAV pada awalnya, dan penulis memutuskan untuk menghapusnya demi REST API yang lebih sederhana, berdasarkan dunia nyata pengujian dan pengalaman dengan itu):

1. CORS

Cara kerja browser adalah aplikasi yang tidak dihosting seperti Laverna terhubung langsung ke server dari JavaScript. Ini disertai dengan pembatasan, bahwa server harus menawarkan header Sumber Daya Lintas Asal untuk semua permintaan dan mendukung permintaan pra-penerbangan OPSI untuk kata kerja HTTP yang dapat memanipulasi data, seperti misalnya POST, PUT, DELETE. Sebagian besar server WebDAV tidak mendukung ini. Jadi banyak server WebDAV tidak kompatibel dengan Laverna di luar kotak.

Masalah: bahkan jika seseorang tidak peduli dengan server yang tidak kompatibel, bagaimana aplikasi mendeteksi jika ada dukungan? Ini sebenarnya dibuat jauh lebih sulit oleh browser yang sengaja tidak memberikan detail kode JS tentang mengapa koneksi gagal, jadi perlu ada semacam mekanisme penemuan. Selain itu, harus dijelaskan kepada pengguna apa sebenarnya yang menjadi penyebabnya dan bahwa mereka mungkin harus berpindah server untuk menggunakan aplikasi.

Solusi di RS: protokol membutuhkan CORS di luar kotak. Juga, penemuan ditangani melalui Webfinger, di mana alamat pengguna dapat mengembalikan semua info konfigurasi, tetapi juga di mana kemampuan tambahan dari server dapat diumumkan.

Solusi untuk WebDAV/Laverna biasa: Ada ide?

2. Izin / Otorisasi

Izin harus ditangani sisi server dan per akun di WebDAV, karena tidak ada hal seperti itu yang dibangun ke dalam protokol. Otorisasi folder tertentu untuk mengakses tidak ada.

Solusi di RS: OAuth 2.0, sehingga pengembang aplikasi dapat memutuskan bagian penyimpanan mana yang mereka perlukan aksesnya, dan pengguna dapat dengan mudah melihat bagian mana itu, dan memutuskan untuk memberikan akses dalam dialog sederhana.

Solusi untuk WebDAV/Laverna biasa: Ini pada dasarnya tidak mungkin, tetapi tentu saja mungkin untuk melewatkan fitur itu dan secara sukarela memberi Laverna akses ke semua data seseorang. Tidak elegan, tetapi tentu saja bukan penghalang untuk implementasi.

3. Dukungan offline/seluler

Ini bukan masalah WebDAV atau diselesaikan hanya dalam spesifikasi RS saja. Tetapi untuk aplikasi web berkemampuan seluler, itu tetap merupakan faktor penting. Koneksi desktop dan seluler turun secara teratur, dan orang tidak ingin catatan mereka tidak disimpan karenanya. Jadi beberapa jenis penyimpanan offline perlu digunakan, dan disinkronkan secara cerdas dengan server jarak jauh (dan tentu saja tanpa autentikasi ulang setelah setiap penurunan jika Anda ingin menciptakan pengalaman pengguna yang baik).

Ada dua masalah disini:

Masalah 1: Server perlu mendukung Etags, sehingga seseorang dapat membangun mekanisme sinkronisasi sejak awal

Solusi di RS: Ini sebagian diselesaikan dalam protokol dengan meminta ETag pada sumber daya direktori dan daftar itemnya, serta dokumen tunggal itu sendiri. Berdasarkan itu, seseorang dapat membangun mekanisme sinkronisasi menggunakan header HTTP seperti misalnya If-None-Match dan tanggapan seperti misalnya 304 s kosong untuk meminta hal-hal yang belum berubah dan 412 untuk menolak menimpa sesuatu yang telah berubah pada perangkat yang berbeda pada waktu yang berbeda.

Solusi untuk WebDAV/Laverna biasa: Sayangnya, dukungan Etag hanya HARUS dalam spesifikasi WebDAV, begitu banyak server tidak mendukungnya, dan beberapa bahkan meminta pengguna mereka secara eksplisit untuk mematikan dukungan, bahkan jika mereka memilikinya, karena itu diterapkan dengan cara yang tidak berkinerja. (Ini sebenarnya bukan masalah yang mudah bagi pengembang server; saya pasti bisa membuktikannya). Tetapi mirip dengan CORS, itu mungkin, jadi solusinya di sini akan kembali ke penemuan fitur dan membimbing pengguna untuk mengonfigurasi server mereka atau memberi tahu mereka bahwa mereka harus beralih ke server lain. Untungnya, ini jauh lebih mudah daripada dengan CORS, karena seseorang dapat mendeteksi ini dari JS dengan memeriksa header respons.

Masalah 2: Tulis mekanisme sinkronisasi yang sebenarnya atau gunakan perpustakaan yang menyediakannya

Solusi di RS: Sejak awal, salah satu penulis spesifikasi mulai membuat pustaka klien referensi untuk memecahkan masalah ini bagi orang-orang yang ingin mengintegrasikan RS ke dalam aplikasi mereka. Itu masih dipertahankan dan dikembangkan dan telah diuji dalam pertempuran di ratusan ribu koneksi, perangkat, OS, browser, di Cordova, dan sebagainya yang berbeda. Itu juga digunakan di Laverna. Komitmen pertama itu kembali ke November 2010, jadi itu jelas bukan "solusi hipster baru". Jika ada bug dengan itu, ada orang yang senang membantu dengan itu, dan umpan balik apa pun selalu dan selalu dihargai (karenanya tanggapan proaktif saya di utas ini).

Solusi untuk WebDAV/Laverna biasa: Salah satu solusi yang mungkin adalah perpustakaan gulung tangan khusus. Upaya untuk membuat, memperbaiki, dan memelihara kode seperti itu pasti akan mengecilkan masalah lain yang saya sebutkan, namun tentu saja sangat mungkin untuk melakukannya. Tantangan utama yang akan saya asumsikan, terlepas dari seribu hal lain untuk diterapkan, mungkin pada akhirnya adalah perilaku variabel server WebDAV, khususnya. implementasi Etag mereka. Namun, jika Anda mengetahui perpustakaan semacam itu (saya tidak mengetahuinya, dan saya juga tidak dapat menemukannya, ketika saya memeriksanya lagi sekarang), akan menjadi sangat mungkin untuk memecahkan masalah luar biasa lainnya dalam beberapa cara dan menyediakan WebDAV untuk pengguna teknis.

Mohon maaf dan tunjukkan kesalahan atau fakta yang salah yang terkandung dalam daftar ini. Saya pada dasarnya menulis semua itu dari atas kepala saya. Saya akan mentransfer ini ke wiki RS dalam waktu dekat, dan meminta beberapa orang untuk meninjau/mengedit apa yang saya tulis, karena menurut saya ini sebenarnya adalah penjelasan yang agak berguna tentang perbedaan antara WebDAV dan RS, dan bagaimana RS menyelesaikan hal-hal yang WebDAV belum, ketika datang ke aplikasi Web sisi klien yang berjalan sepenuhnya di browser (yang dapat dimengerti, karena kemampuan platform Web tidak benar-benar ada saat itu dan seluruh konsep aplikasi web offline-pertama bukanlah hal).

@technodrome Jika Anda ingin memajukan tujuan Anda untuk mendapatkan dukungan WebDAV, maka menunjukkan solusi potensial untuk salah satu masalah ini (atau fakta yang membatalkannya sepenuhnya) mungkin akan sangat membantu.

Maaf, tetapi jika Anda tidak dapat memahami perspektif pengguna akal sehat karena Anda merasa itu menyakiti perasaan atau pendapat Anda, maka masalahnya ada pada Anda. Perangkat lunak yang ditujukan untuk orang-orang secara definisi digunakan oleh lebih dari satu orang - bukan hanya Anda. Dengan demikian, setiap orang harus diundang untuk memberikan pendapat karena brainstorming dan ide-ide adalah yang mendorong proyek ke depan. Dan dilihat dari orang-orang yang mengeluarkan +1 untuk webDav atau dukungan protokol standar lainnya, bukan hanya saya.

Anda mencoba memutarbalikkan apa yang saya katakan dan menganggapnya pribadi meskipun itu dimaksudkan sebagai pendapat pribadi pada tingkat umum. Tetapi to the point - jika pengembang tidak menawarkan metode standar untuk menyimpan data pengguna, maka ya - ia mempersenjatai pengguna dengan kuat untuk menggunakan preferensi pengembang.

Pengguna yang paham teknologi tidak sama dengan programmer. Jangan langsung mengambil kesimpulan hanya karena itu sesuai dengan retorika Anda.

Juga, saya dengan jelas mengatakan saya menghargai pekerjaan dan usaha dan saya benar-benar melakukannya. Itu tidak berarti saya akan secara membabi buta setuju dengan semuanya hanya karena Anda mengatakannya. Ini adalah hak saya dan juga milik Anda dan ada jutaan cara untuk memecahkan masalah ini. Tentu saja Anda mendorong produk Anda, tetapi mari kita sedikit demokratis di sini dan menawarkan kebebasan memilih yang cocok untuk lebih banyak orang, bukan hanya Anda.

Meskipun Anda mencantumkan banyak alasan mengapa itu tidak dapat bekerja dan mengapa solusi RS Anda adalah obat untuk setiap rasa sakit, saya yakin titik akhir perantara (aplikasi Go?) yang berjalan sebagai daemon lokal (klien, server) dapat menangani otorisasi dan memungkinkan sejumlah kemungkinan untuk mengintegrasikan hampir semua protokol yang Anda inginkan. Ini pasti membawa lebih sedikit sakit kepala daripada mempertahankan seluruh tumpukan teknologi, yang mungkin atau mungkin tidak dilupakan dan usang dalam dua tahun.

Juga, komentar saya tidak dimaksudkan untuk membuktikan siapa pun salah, hanya untuk mengatakan ada standar industri tertentu dan ada alasan mengapa hal-hal menjadi standar seperti itu. Jika Anda tidak dapat memahaminya, saya khawatir tidak ada argumentasi yang dapat meyakinkan Anda tentang kebenaran lain selain kebenaran Anda.

Yah, saya membaca argumen yang bagus di kedua sisi. Akhirnya memiliki penyimpanan saya adalah persyaratan bagi saya, dan pergi ke turtl karena penyimpanan (terenkripsi) di server adalah bagian dari inti proyek.
Seperti yang disebutkan sebelumnya, jika suatu produk tidak sesuai dengan semua kebutuhan Anda, dan dalam hal itu tampaknya ada alasan untuk itu (yang tentu saja masih dapat diperdebatkan), maka carilah sesuatu yang lebih dekat dengan kebutuhan dan persyaratan Anda.
Saya yakin banyak orang baik-baik saja dengan meng-hosting file mereka di Dropbox. Tidak perlu bekerja keras, terutama pada produk open source. Saya mengerti dan berbagi rasa frustrasi, tetapi open source memiliki banyak rencana bisnis, dan terkadang mereka tidak memenuhi persyaratan kami. Hanya harus menghadapinya.

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

Maaf, tetapi jika Anda tidak dapat memahami perspektif pengguna yang masuk akal
karena Anda merasa itu menyakiti perasaan atau pendapat Anda, maka masalahnya
adalah dengan Anda. Perangkat lunak yang ditujukan untuk orang-orang secara definisi digunakan oleh:
lebih dari satu orang - bukan hanya Anda. Karena itu, setiap orang harus
diundang untuk memberikan pendapat karena brainstorming dan ide adalah apa
mendorong proyek ke depan. Dan dilihat dari orang-orang yang mengeluarkan +1 untuk
webDav atau dukungan protokol standar lainnya, bukan hanya saya.

Anda mencoba memutarbalikkan apa yang saya katakan dan menganggapnya pribadi bahkan
meskipun mereka dimaksudkan sebagai pendapat pribadi pada tingkat umum. Tapi untuk
intinya - jika pengembang tidak menawarkan metode standar apa pun dari
menyimpan data pengguna, maka ya - dia mempersenjatai pengguna dengan kuat untuk
gunakan preferensi dev.

Pengguna yang paham teknologi tidak sama dengan programmer. Jangan langsung mengambil kesimpulan
hanya karena itu cocok dengan retorika Anda.

Juga, saya dengan jelas mengatakan saya menghargai pekerjaan dan usaha dan saya benar-benar melakukannya.
Itu tidak berarti saya akan secara membabi buta setuju dengan semuanya hanya karena
kamu bilang begitu. Ini adalah hak saya seperti milik Anda dan ada sejuta cara
bagaimana cara menyelesaikan masalah ini. Tentu saja Anda mendorong Anda
produk tapi mari kita menjadi sedikit demokratis di sini dan menawarkan kebebasan
pilihan yang cocok untuk lebih banyak orang, bukan hanya Anda.

Meskipun Anda mencantumkan banyak alasan mengapa itu tidak dapat bekerja dan mengapa Anda
Solusi RS adalah obat untuk setiap sakit, saya yakin perantaranya
titik akhir (Aplikasi Go?) berjalan sebagai daemon lokal (klien, server) dapat
mengurus otorisasi dan memungkinkan sejumlah kemungkinan untuk
mengintegrasikan hampir semua protokol yang Anda inginkan. Itu pasti membawa lebih sedikit
sakit kepala daripada mempertahankan seluruh tumpukan teknologi, yang mungkin atau mungkin
tidak akan terlupakan dan usang dalam dua tahun.

Juga, komentar saya tidak dimaksudkan untuk membuktikan siapa pun salah, hanya untuk mengatakan
ada standar industri tertentu dan ada alasan mengapa banyak hal
menjadi standar seperti itu. Jika Anda tidak dapat memahaminya, saya khawatir
tidak ada argumentasi yang dapat meyakinkan Anda tentang kebenaran lain
daripada milikmu.

--
Anda menerima ini karena Anda berkomentar.
Balas email ini secara langsung atau lihat di GitHub:
https://github.com/Laverna/laverna/issues/6#issuecomment -282279742

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

Dengan demikian, setiap orang harus diundang untuk memberikan pendapat karena brainstorming dan ide-ide adalah yang mendorong proyek ke depan. Dan dilihat dari orang-orang yang mengeluarkan +1 untuk webDav atau dukungan protokol standar lainnya, bukan hanya saya.

Ya! Saya menyatakan dengan tepat dan kemudian menghabiskan waktu dan usaha untuk menunjukkan apa yang menurut saya perlu diselesaikan untuk memenuhi keinginan Anda. Saya tidak memutar apa pun untuk "sesuai dengan agenda saya", dan saya secara aktif mengundang Anda dan siapa pun untuk menunjukkan kesalahan apa pun yang terkandung dalam analisis objektif saya dan saya juga mengundang Anda untuk membantu memajukan implementasi preferensi/ide Anda sendiri.

Sayangnya, tidak mudah untuk menemukan argumen substansial atau fakta baru di antara tuduhan dalam komentar lanjutan Anda. Tapi satu paragraf mengandung setidaknya sebuah ide:

Saya yakin titik akhir perantara (Aplikasi Go?) yang berjalan sebagai daemon lokal (klien, server) dapat menangani otorisasi dan memungkinkan sejumlah kemungkinan untuk mengintegrasikan hampir semua protokol yang Anda inginkan

Jadi ya, itu tentu saja mungkin secara teori. Masalahnya adalah bahwa itu benar-benar bertentangan dengan pendapat dan argumen Anda sendiri dalam paragraf yang sama:

Ini pasti membawa lebih sedikit sakit kepala daripada mempertahankan seluruh tumpukan teknologi, yang mungkin atau mungkin tidak dilupakan dan usang dalam dua tahun.

Ide Anda akan benar-benar berarti: membuat, menguji, dan memelihara setumpuk teknologi baru ("klien, server") agar aplikasi web dapat menyimpan data dari jarak jauh, dan menyinkronkannya di seluruh perangkat. Terlepas dari masalah menemukan dan memelihara tumpukan baru ini, juga akan agak sulit untuk menjalankan program lokal itu di semua perangkat Anda, yang terpenting perangkat seluler.

Juga, komentar saya tidak dimaksudkan untuk membuktikan siapa pun salah, hanya untuk mengatakan ada standar industri tertentu dan ada alasan mengapa hal-hal menjadi standar seperti itu.

Saya sepenuhnya setuju dengan itu! Dan saya menjelaskan panjang lebar mengapa WebDAV memang tidak menjadi standar untuk aplikasi web sisi klien, dan mengapa protokol RS dibuat --awalnya dengan WebDAV sebagai API bahkan-- sebagai standar baru untuk membuat per-pengguna, di-host-sendiri penyimpanan mungkin untuk jenis aplikasi yang tepat ini.

Ini sebenarnya protokol yang agak sederhana dan kebalikan dari "tumpukan teknologi". Jika Anda belum melihat penjelasan singkat tentang bagian-bagiannya, Anda dapat menemukannya di situs web ini . -- Juga, mengenai "webDav atau dukungan protokol standar lainnya", itulah tepatnya yang dimaksud dengan RS .

Sekarang, Anda tentu saja mungkin merasa negatif tentang WebDAV yang tidak menjadi solusi yang terlalu layak untuk aplikasi web sisi klien, tetapi itu tidak mengubah fakta yang ada, atau membuat saya menjadi bajingan egois karena menunjukkannya. Tolong, tolong , mari kita diskusikan ini secara rasional, dan jauhkan tuduhan pribadi darinya. Saya benar-benar hanya mencoba membantu, dan sama sekali tidak perlu hal-hal negatif. Sekali lagi: Saya sebenarnya mencoba membantu Anda mencapai tujuan Anda, dan saya jelas tidak berdebat agar RS menjadi solusi eksklusif sama sekali. Jika ada yang bisa menemukan solusi lain, yang mencapai tujuan yang sama, maka saya orang terakhir yang menentangnya berdasarkan preferensi atau ideologi pribadi.

Laverna, sebagai aplikasi web, hanya dapat mendukung HTTP sebagai protokol transfer dan membutuhkan CORS agar semuanya berfungsi. Namun untuk beberapa alasan orang mengusulkan hal-hal seperti BitTorrent Sync atau WebDAV, salah satunya tidak berjalan melalui HTTP dan tidak ada yang memiliki CORS sebagai bagian dari spesifikasinya. Bahkan yang pertama bahkan tidak memiliki spesifikasi, itu adalah protokol berpemilik. @technodrome bahkan menyebut penggunaan WebDAV "perspektif pengguna akal sehat", meskipun, sekali lagi, menggunakan WebDAV dari aplikasi Javascript dalam browser tidak berfungsi dalam kasus umum dan karenanya tidak masuk akal, terlepas dari perspektif . Pembicaraan tentang menggunakan proxy perantara untuk menambahkan tajuk CORS juga tidak cocok dengan ide saya tentang UX yang bagus.

Saya pikir ini benar-benar menunjukkan bahwa diskusi ini sebagian besar didominasi oleh orang-orang yang menginginkan "kebebasan perangkat lunak umum" dan membuang nama-nama beberapa protokol yang sudah ada, bukan orang-orang yang benar-benar serius melihat salah satu opsi tersebut dari perspektif teknis dan memutuskan apakah mereka adalah alat yang tepat untuk pekerjaan itu. Sekali lagi saya ingin memanggil @technodrome, yang selain marah-marah karena dia (dimengerti) memandang @skddc 's advokasi untuk remoteStorage sebagai shilling mendorong agenda sendiri, pada saat yang @skddc yang sama adalah yang pertama di thread ini untuk membuat argumen yang layak untuk protokol yang dia usulkan.

Mungkin kita harus mengakui bahwa bahkan setelah tiga tahun masalah ini dibuka, tidak ada standar untuk ini. Yang meninggalkan kita dengan tiga pilihan:

1. Bertaruh pada Penyimpanan jarak jauh, belum standar
2. Tetap gunakan WebDAV, tetapi perlu header CORS. Secara efektif ini berarti hanya dukungan untuk NextCloud dan ownCloud.
3. Tulis plugin NextCloud khusus, dengan API khusus

Iklan 1: remoteStorage sebagai protokol cukup bagus, tetapi saya rasa pustaka klien belum ada di sana. Sebenarnya pengalaman terakhir yang saya miliki dengan remoteStorage.js (perpustakaan klien) tidak baik. Semuanya berfungsi, namun masih ada bug kecil di mana-mana dan saya hanya tidak menganggap API "pemodelan data" tingkat tinggi dapat digunakan. Bagian terakhir seharusnya tidak menjadi masalah, mengingat Anda hanya dapat menulis model data Anda sendiri dan membaca dan menulis file mentah.

Iklan 2: Ini benar-benar berfungsi, tetapi sekarang Anda telah membatasi diri Anda pada NextCloud/ownCloud sementara harus berurusan dengan kompleksitas WebDAV yang mengerikan. Saya pikir saya dapat berbicara untuk semua orang yang pernah bekerja dengan protokol itu ketika saya mengatakan bahwa penggunaan WebDAV hanya demi menggunakan standar tidak layak jika pengguna tidak mendapat manfaat darinya.

Mengingat Laverna sudah memiliki dukungan remoteStorage, saya kira menginvestasikan lebih banyak waktu dalam memperbaiki pustaka klien rs.js adalah cara yang baik untuk maju, meskipun kita mungkin memerlukan dukungan NextCloud bagi siapa saja untuk menggunakan backend itu. Aplikasi NextCloud khusus juga merupakan pilihan IMO yang bagus, meskipun itu kehilangan tujuan untuk memiliki standar lebih banyak lagi.

Halo,
Silakan laporkan ke https://github.com/Laverna/laverna/issues/971#issuecomment -411423965 yang menjelaskan status proyek ini.

Selamat siang/malam,
Bersulang,
Nissar