Libelektra: Perpustakaan untuk jenis

Saya pikir itu harus menjadi cara luar biasa untuk membentuk perpustakaan berdasarkan proposal. Jauh lebih masuk akal untuk mengekstrak fungsionalitas umum antara plugin dan membuat perpustakaan dari itu. Plugin TOML @bauhaus93 memiliki banyak kode yang masuk akal untuk dimasukkan ke dalam perpustakaan (misalnya kode penanganan komentar).

Jangan salah paham, ini masukan yang bagus untuk @bauhaus93. Dan jika ada plugin kedua yang membutuhkan fungsi yang sama, kita pasti harus memasukkannya ke dalam library. Tetapi membuat perpustakaan jauh lebih sulit daripada memiliki kode khusus plugin dan upaya itu hanya boleh dilakukan jika sebenarnya ada setidaknya dua pelanggan.

@bauhaus93 jika Anda tidak melihat manfaat langsung dalam memiliki perpustakaan jenis (misalnya penggunaan kembali dengan plugin lain), tutup masalah ini.

jika ada plugin kedua yang membutuhkan fungsi yang sama, kita pasti harus memasukkannya ke dalam perpustakaan

Selama pengembang plugin kedua tahu di mana menemukan plugin pertama dan cara mengekstrak kode dari sana tanpa merusak semuanya, itu adalah strategi yang bagus ya. Sayangnya, hal ini sering tidak terjadi. Terutama, karena seringkali plugin pertama harus diubah secara ekstensif agar dapat menggunakan perpustakaan.

Juga memiliki perpustakaan mungkin benar-benar mendorong seseorang untuk menulis plugin penyimpanan baru, karena beberapa pekerjaan sudah selesai.

Tapi saya menandai ini sebagai low priority , tepatnya karena saya tahu ini banyak pekerjaan dan mungkin tidak ada orang yang mau melakukannya.

Untuk tipe, saya tidak yakin tentang dapat digunakan kembali, kecuali mungkin validasi/konversi bilangan bulat non-desimal (biner/oktal/heksadesimal) atau datetimes (TOML menggunakan RFC 3339 datetimes).
Tidak terkait dengan tipe, saya melihat beberapa kegunaan kembali dalam persiapan KeySets yang akan ditulis (mis. fungsi yang memperbarui/menambahkan array metakeys, menghapus array metakeys dari array yang tidak valid atau menyelesaikan comment/#X hilang

Anda mungkin belum menyadarinya, tetapi mungkin juga ada masalah dengan normalisasi boolean seperti yang dilakukan plugin tipe. Ini mungkin kode yang paling sering digunakan kembali, karena sebagian besar format akan menggunakan true / false tetapi Elektra menggunakan 1 / 0 . Saya pikir yamlcpp harus menambahkan beberapa kode khusus, sehingga boolean tidak akan diubah menjadi bilangan bulat atau sebaliknya (atau sesuatu seperti itu).

Ah ya, lupakan itu, plugin TOML juga harus menormalkan nilai-nilai ini.

Masalahnya bukan hanya, Anda harus menormalkan nilainya. Anda juga harus tahu persis apa yang type Plugin tidak, karena berjalan sebelum toml Plugin di kdbSet fase. Saya tidak yakin, apakah kami pernah menerapkannya, tetapi Anda juga harus memastikan bahwa plugin type hanya menghasilkan 1 / 0 atau true / false dalam fase kdbSet , terlepas dari konfigurasi yang disediakan pengguna. Jika tidak, toml harus dapat mengurai konfigurasi plugin type , karena pengguna dapat menetapkan nilai true dan false khusus (lihat kasus uji di bawah)

https://github.com/ElektraInitiative/libelektra/blob/4b0e9f8bdd6d890a1a3abaf04c543b9c7d33e984/src/plugins/type/testmod_type.c#L734 -L771

Bagian yang menarik adalah:

https://github.com/ElektraInitiative/libelektra/blob/4b0e9f8bdd6d890a1a3abaf04c543b9c7d33e984/src/plugins/type/testmod_type.c#L749 -L753

Plugin type menerima 1 di kdbGet (bisa dari toml ), tetapi mengembalikan t di kdbSet . Ini bisa sejauh pengguna mendefinisikan true = 0 dan false = 1 yang benar-benar akan membingungkan plugin toml . (Saya pikir semua boolean akan aktif setiap kdbSet )

Interaksi yang sangat kompleks ini adalah mengapa saya pikir plugin type seharusnya untuk format penyimpanan yang tidak memiliki tipe dan mereka yang memilikinya harus secara eksplisit melarang penggunaan type . Tetapi untuk membuatnya layak, kita memerlukan cara mudah untuk mendukung tipe di dalam plugin penyimpanan, yaitu perpustakaan tipe.

Karena plugin toml juga menangani bilangan heksadesimal, plugin ini mungkin juga secara eksplisit melarang penggunaan plugin hexnumber . (walaupun dalam kasus itu ada potensi masalah yang lebih kecil menurut saya)

Juga memiliki perpustakaan mungkin benar-benar mendorong seseorang untuk menulis plugin penyimpanan baru, karena beberapa pekerjaan sudah selesai.

Sebagian besar pengguna mungkin hanya ingin menulis tata bahasa dan sisanya secara ajaib akan terjadi dengan sendirinya. Saya bertanya-tanya seberapa jauh plugin TOML @bauhaus93 benar-benar mencapai tujuan ini. Akan menarik untuk membuat plugin non-TOML dengan basis kode dari plugin TOML. Namun, perpustakaan tipe saja menurut saya terlalu khusus untuk terlalu berguna untuk tugas besar "menulis plugin penyimpanan".

Untuk tipe, saya tidak yakin tentang dapat digunakan kembali, kecuali mungkin validasi/konversi bilangan bulat non-desimal (biner/oktal/heksadesimal) atau datetimes (TOML menggunakan RFC 3339 datetimes).

Tanggal/waktu ada di Elektra hanya untuk validasi tetapi hanya RFC2822 yang didukung. Plugin tanggal dapat menggunakan kembali parser Anda untuk memvalidasi RFC 3339 tetapi saya akan menganggap ini sebagai prioritas yang sangat rendah.

Apa yang akan sedikit lebih menarik adalah sesuatu seperti keyGetDateTime(Key *k, struct tm *tm) dari kunci dengan tanggal (TOML).

Tidak terkait dengan tipe, saya melihat beberapa kegunaan ulang dalam persiapan KeySet yang akan ditulis (mis. fungsi yang memperbarui/menambah metakey array, menghapus metakey array dari array yang tidak valid atau menyelesaikan komentar yang hilang/data metakey #X).

Ya, itu bisa menarik. Tetapi yang lebih menarik adalah kemungkinan untuk secara langsung memodifikasi tata bahasa dan kode sentuh sesedikit mungkin :wink:

Anda mungkin belum menyadarinya, tetapi mungkin juga ada masalah dengan normalisasi boolean seperti yang dilakukan plugin tipe.

Apa yang hilang adalah beberapa tutorial/penjelasan di doc/tutorials/storage-plugins.md yang memberikan tampilan terkini tentang plugin mana yang sebenarnya harus diandalkan oleh plugin penyimpanan. #2330 akan menunjukkan jika "biner" dapat dibutuhkan dan masih cocok sebagai penyimpanan default.

Anda juga harus tahu persis apa yang dilakukan plugin jenis, karena ia berjalan sebelum plugin toml di fase kdbSet.

Mungkin, plugin penyimpanan harus berhenti menggunakan plugin tipe dan hanya melakukan normalisasi sendiri (dari apa pun yang benar/salah dalam formatnya hingga 1/0 di Elektra dan seterusnya). @bauhaus93 fungsi lain dari jenis plugin mana yang Anda gunakan?

Ini bisa sejauh pengguna mendefinisikan bahwa true = 0 dan false = 1 yang benar-benar akan membingungkan plugin toml.

Saya akan mendukung pengurangan fungsionalitas plugin tipe. Jika ada, beberapa nilai true/false tambahan harus dapat ditentukan oleh pengguna (yang jelas-jelas bukan nilai true/false sebelumnya).

Karena plugin toml juga menangani angka heksadesimal, plugin ini mungkin juga secara eksplisit melarang penggunaan plugin hexnumber. (walaupun dalam kasus itu ada potensi masalah yang lebih kecil menurut saya)

Tidak ada cara untuk menyatakan bahwa plugin tidak bekerja bersama (Memiliki fungsi seperti itu akan membuat pemasangan jauh lebih rumit. Juga akan terlalu banyak pekerjaan bagi kami untuk mempertahankan tabel plugin mana yang berfungsi dengan plugin mana.). Tapi mungkin tidak ada yang akan memiliki ide untuk menggunakannya bersama-sama, karena plugin TOML sudah memiliki fungsi ini dan banyak lagi (misalnya juga bilangan biner).

Sebagian besar pengguna mungkin hanya ingin menulis tata bahasa dan sisanya secara ajaib akan terjadi dengan sendirinya.

Itu tampaknya agak terlalu ajaib untuk menjadi mungkin. Ini mungkin dilakukan dengan pembuat kode khusus berdasarkan tata bahasa Yacc atau ANTLR yang dimodifikasi. Tapi saya tidak berpikir ada cara untuk memiliki kode yang membuat KeySet s hanya dari tata bahasa untuk format yang sangat berbeda seperti JSON, XML, TOML dan edn . Seperti yang ditemukan @'sansecours, ada juga format seperti YAML yang sangat sulit diungkapkan dalam format tata bahasa standar.

Namun, perpustakaan tipe saja menurut saya terlalu khusus untuk terlalu berguna untuk tugas besar "menulis plugin penyimpanan".

Kita tentu saja dapat memperluas perpustakaan menjadi perpustakaan storage yang menyediakan lebih banyak fungsi pembantu untuk plugin penyimpanan (misalnya berurusan dengan stdin / stdout dan pipa untuk impor/ekspor). Jenis barang kemudian akan menjadi bagian dari itu.

Saya juga berpikir Anda meremehkan betapa rumitnya jenis barang itu. Jika kita memiliki perpustakaan tipe standar, memperluas sistem tipe juga akan lebih mudah misalnya untuk menyimpan versi biner pra-parsing dari bilangan bulat sebagai tambahan (ke versi string untuk mengurangi overhead parsing). Pustaka storage juga dapat menggunakan API internal (jika diperlukan), karena dikelola oleh pengembang Elektra.

Pustaka tipe standar lainnya juga akan menjamin pesan kesalahan standar untuk masalah tipe. Jadi bahkan akan ada keuntungan bagi pengguna akhir.

Apa yang akan sedikit lebih menarik adalah sesuatu seperti keyGetDateTime(Key *k, struct tm *tm)

Kedengarannya seperti pekerjaan untuk bagian konversi libease (sebagai elektraKeyToDateTime (const Key * key, struct tm * dateTime) ).

@bauhaus93 fungsi di sana mungkin berguna untuk toml juga. Mereka dirancang sedemikian rupa sehingga misalnya elektraKeyToFloat dan elektraFloatToString pulang pergi dengan sempurna dan tanpa kerugian (tidak peduli jika Anda memulai dengan float string) dan mereka juga digunakan di API tingkat tinggi. Jadi jika toml membuat kunci dengan elektra*ToString itu pasti dapat dibaca dengan benar oleh API tingkat tinggi dan toml pasti dapat membaca dengan benar apa pun yang dihasilkan oleh highlevel API elektraKeyTo* .

tampilan terkini tentang plugin mana yang seharusnya diandalkan oleh plugin penyimpanan.

IMO, plugin penyimpanan tidak boleh _bergantung_ pada plugin lain. Plugin penyimpanan dapat ditingkatkan dengan plugin lain, tetapi mereka idealnya bekerja secara mandiri.

Bahkan berurusan dengan kunci biner, akan lebih baik diselesaikan dengan perpustakaan penyimpanan/tipe. Sekali lagi itu menjamin beberapa standar dasar untuk pesan kesalahan dll. Ini juga menghindari penggunaan plugin binary untuk format yang tidak membutuhkannya. Meskipun binary digabungkan dengan misalnya quickdump akan berfungsi, ini buruk untuk kecepatan dan ukuran penyimpanan.

Mungkin, plugin penyimpanan harus berhenti menggunakan plugin tipe dan cukup melakukan normalisasinya sendiri

Itulah sebabnya saya mengusulkan perpustakaan. Jauh lebih baik untuk menyediakan perpustakaan yang berfungsi daripada hanya memberikan deskripsi informal (atau bahkan spesifikasi formal) tentang apa yang harus dilakukan plugin. Apalagi jika spesifikasinya bisa berubah seiring waktu.

Saya akan mendukung pengurangan fungsionalitas plugin tipe.

Mengapa menghilangkan fungsionalitas yang sudah diterapkan? Awalnya, idenya adalah untuk memiliki plugin boolean , tetapi itu juga menyebabkan masalah, karena pemesanan plugin dan hal-hal semacam itu.

Jika ada, beberapa nilai true/false tambahan harus dapat ditentukan oleh pengguna (yang jelas-jelas bukan nilai true/false sebelumnya).

Benar-benar tidak perlu untuk itu. Hanya ada masalah, jika lebih dari satu plugin mendefinisikan apa itu nilai boolean.

Bahkan true = 0 dan false = 1 baik-baik saja. Elektra sendiri mendenda boolean sebagai " 1 adalah satu-satunya nilai yang benar dan 0 adalah satu-satunya nilai yang salah".

Tidak ada cara untuk menyatakan bahwa plugin tidak bekerja bersama (Memiliki fungsi seperti itu akan membuat pemasangan jauh lebih rumit. Juga akan terlalu banyak pekerjaan bagi kami untuk mempertahankan tabel plugin mana yang berfungsi dengan plugin mana.).

saya tidak setuju. Daftar lengkap tentu saja tidak mungkin (bagaimanapun juga ada plugin pihak ketiga), tetapi solusinya sederhana. Biarkan plugin melakukan pemeriksaan sendiri. Baik dalam elektra<Plugin>Get atau dalam fungsi lain yang dipanggil selama kdb mount .

Selain boolean, plugin TOML juga menyetel tipe string, double dan (unsigned_)long_long saat membaca.

Saya setuju dengan @kodebach , bahwa plugin type hanya boleh digunakan oleh plugin tanpa sistem tipe bawaan , karena kesulitan dalam interaksi.
Misalnya. plugin TOML menyetel metakey type untuk bilangan bulat saat membaca juga pada nilai non-desimal (sambil mengonversinya menjadi desimal, menyimpan representasi non-desimal dalam origvalue ). Namun, jika Anda ingin mengubah nilai yang diketik dengan kdb set (dan melakukannya dengan nilai biner/oktal/hex), Anda tidak dapat melakukannya secara langsung (dengan menetapkan nilai kunci), karena type Pemeriksaan jenis plugin origvalue sebagai gantinya. (Menghapus metakey type sebelum menetapkan nilai baru tidak akan berfungsi, karena metakey akan disetel ulang saat membaca.)

Masalahnya bukan hanya, Anda harus menormalkan nilainya. Anda juga harus tahu persis apa yang dilakukan plugin jenis, karena ia berjalan sebelum plugin toml di fase kdbSet. Saya tidak yakin, apakah kami pernah menerapkannya, tetapi Anda juga harus memastikan bahwa jenis plugin hanya menghasilkan 1/0 atau benar/salah dalam fase kdbSet, terlepas dari konfigurasi yang disediakan pengguna. Jika tidak, toml harus dapat mengurai konfigurasi plugin tipe, karena pengguna dapat menetapkan nilai true dan false khusus (lihat kasus uji di bawah)

Ya saya sudah bertanya-tanya, apakah/bagaimana saya benar-benar dapat memeriksa nilai boolean yang ditentukan pengguna. Saat ini, saat penulisan, plugin TOML hanya menganggap nilai "1" dan "true" sebagai benar, sisanya akan dianggap salah.

@kodebach menulis:

Itu tampaknya agak terlalu ajaib untuk menjadi mungkin.

Dengan Augeas itu mungkin (tetapi pohon yang Anda dapatkan tidak begitu diinginkan). Akan menarik seberapa jauh kita dengan solusi TOML saat ini. Tentu saja Anda perlu menulis beberapa kode emitor tetapi ini biasanya tidak terlalu dramatis.

JSON, XML

Ini adalah keuntungan dari Elektra bahwa format yang sangat berbeda dapat diimplementasikan dalam teknologi yang berbeda. Mencoba mengimplementasikan XML dari awal mungkin bukan ide terbaik. Jika format seperti INI bisa dicakup, itu sudah luar biasa.

Tapi tentu saja yang pertama dan terpenting adalah mendapatkan plugin TOML yang bagus :1st_place_medal:

Pustaka tipe standar lainnya juga akan menjamin pesan kesalahan standar untuk masalah tipe.

Pengecekan dapat dengan mudah dilakukan di plugin lain (setelah #2963 selesai). Jika sebuah plugin hanya memeriksa dan gagal dengan pesan kesalahan yang indah, ada sedikit/tidak ada interaksi.

Kedengarannya seperti pekerjaan untuk bagian konversi libease

Ya, mungkin beberapa barang dari TOML bisa masuk ke libease atau libmeta.

IMO, plugin penyimpanan tidak boleh bergantung pada plugin lain.

Untuk biner saya belum yakin (karena ini mungkin sesuatu yang tidak diperlukan untuk backend default), untuk semua fungsi lainnya, ini juga kesimpulan saya. Namun, kesimpulan ini belum diterima secara luas (@sanssecours?) atau didokumentasikan.

Itulah sebabnya saya mengusulkan perpustakaan. Jauh lebih baik untuk menyediakan perpustakaan yang berfungsi daripada hanya memberikan deskripsi informal (atau bahkan spesifikasi formal) tentang apa yang harus dilakukan plugin. Apalagi jika spesifikasinya bisa berubah seiring waktu.

Itu tergantung: jika ada sejumlah besar kemungkinan yang valid, tutorial/deskripsi mungkin lebih baik daripada perpustakaan rumit yang entah bagaimana mencoba memberikan fleksibilitas ini. Dan untuk serialisasi ada banyak sekali kemungkinan valid dan banyak dari mereka memiliki implementasi sepele (misalnya hanya memanggil elektraFormat dengan beberapa parameter) hingga implementasi yang rumit (misalnya jika mereka mendukung banyak representasi kenyamanan).

Mengapa menghilangkan fungsionalitas yang sudah diterapkan?

Elektra saat ini runtuh karena beban mempertahankan terlalu banyak kode. Setiap baris kode yang tidak berguna (dalam arti tidak ada yang menggunakannya) yang kami singkirkan membuat Elektra lebih baik.

Sayangnya, bahkan kode yang dipisahkan dalam plugin menimbulkan masalah: misalnya pada server build atau setelah pengguna mencoba menggunakannya, ada interaksi yang tidak diinginkan/dokumen yang hilang/...

Kami tidak dapat merilis semua yang kami miliki saat ini sebagai 1.0, Elektra akan mengecewakan. Kita perlu menyingkirkan segala sesuatu yang tidak diperlukan. Kami menghargai setiap pembersihan yang dapat Anda lakukan.

Itu juga alasan mengapa TOML akan menggantikan INI. #3491

Biarkan plugin melakukan pemeriksaan sendiri.

Ini jarang menjadi solusi yang baik. Itu menjadi sangat tidak konsisten dan urutan penambahan plugin mungkin menghasilkan hasil yang berbeda. Apakah kode seperti itu sudah ada di suatu tempat?

@bauhaus93 menulis:

Selain boolean, plugin TOML juga menyetel tipe string, double dan (unsigned_)long_long saat membaca.

Tapi itu semua melakukannya dengan sendirinya tanpa jenis plugin? Untuk apa jenis plugin yang digunakan?

Anda harus mengubah metakey origvalue sebagai gantinya.

Ya, di sini kami belum memiliki solusi yang bagus (#3056). keySetString menghapus origvalue tetapi entah bagaimana perilakunya masih tidak seperti yang diharapkan pengguna.

Saat ini, saat penulisan, plugin TOML hanya menganggap nilai "1" dan "benar" sebagai benar, sisanya akan dianggap salah.

Mungkin kita harus lebih ketat dan gagal dalam segala hal bukan "0" atau "1". Dalam file TOML itu sendiri Anda juga hanya mengizinkan "benar" dan "salah" dan tidak ada yang lain?

Tapi itu semua melakukannya dengan sendirinya tanpa jenis plugin? Untuk apa jenis plugin yang digunakan?

Ya, ia melakukannya dengan sendirinya, berbagai jenis akan dicocokkan selama lexing. Namun, itu tidak memeriksa apakah nilai desimal/ganda over-/underflow long_long / double , jadi saya pikir itu dilakukan oleh plugin type .

Mungkin kita harus lebih ketat dan gagal dalam segala hal bukan "0" atau "1". Dalam file TOML itu sendiri Anda juga hanya mengizinkan "benar" dan "salah" dan tidak ada yang lain?

Ya, saya bisa membuatnya lebih ketat. Dalam file itu sendiri hanya true atau false yang ditulis/dibaca sebagai boolean.

untuk semua fungsi lainnya, ini juga kesimpulan saya.

Dalam hal ini kita membutuhkan perpustakaan type . Kalau tidak, plugin penyimpanan apa pun untuk format dengan tipe akan mengimplementasikan kembali tipe barang (karena mengandalkan plugin lain tidak mungkin).

jika ada banyak kemungkinan yang valid, tutorial/deskripsi mungkin lebih baik

Tetapi dalam hal ini plugin terpisah juga bukan solusi, karena ada juga sejumlah besar kemungkinan interaksi yang perlu dipertimbangkan di kedua plugin.

Apakah kode seperti itu sudah ada di suatu tempat?

AFAIK tidak Saya bahkan tidak yakin sebuah plugin dapat mendeteksi plugin lain mana yang dipasang.

Tapi itu semua melakukannya dengan sendirinya tanpa jenis plugin? Untuk apa jenis plugin yang digunakan?

Ya, ia melakukannya dengan sendirinya, berbagai jenis akan dicocokkan selama lexing. Namun, itu tidak memeriksa apakah nilai desimal/ganda over-/underflow long_long / double , jadi saya pikir itu dilakukan oleh plugin type .

Ya type juga melakukan pemeriksaan jangkauan, memvalidasi float / double dan beberapa hal lain seperti enum s.

Mungkin kita harus lebih ketat dan gagal dalam segala hal bukan "0" atau "1". Dalam file TOML itu sendiri Anda juga hanya mengizinkan "benar" dan "salah" dan tidak ada yang lain?

Dan itulah salah satu kasus yang sangat kompleks dan rumit untuk tipe atau lebih khusus lagi konversi/normalisasi.

Mari kita asumsikan toml hanya menerima true / false sebagai input dan hanya menghasilkan 0 / 1 di kdbGet dan itu hanya menerima 0 / 1 dan hanya menghasilkan true / false di kdbSet . Itu akan sesuai dengan spesifikasi Elektra dan spesifikasi TOML untuk boolean. Tetapi pengguna mungkin berharap bahwa kdb set /some/key/mounted/with/toml true akan berfungsi. Namun, tidak. Dengan konfigurasi yang benar untuk type mungkin berhasil, tetapi dengan cepat menjadi canggung. Misalnya, bagaimana jika kunci itu memang ada sebelumnya. Maka tidak ada type metakey dan type Plugin hanya mengabaikannya, toml menerima true dan mengeluh bahwa true tidak valid boolean...

Ini hanya menunjukkan bahwa plugin penyimpanan HARUS dapat menangani semua jenis yang didukung oleh format penyimpanan dan konversi terkait TANPA menggunakan plugin lain.

Elektra saat ini runtuh karena beban mempertahankan terlalu banyak kode. Setiap baris kode yang tidak berguna (dalam arti tidak ada yang menggunakannya) yang kami singkirkan membuat Elektra lebih baik.

Itu adalah poin yang adil, meskipun saya tidak berpikir hanya menghapus kode adalah solusi yang tepat. Setidaknya tidak ketika datang ke plugin. Dalam inti, saya setuju, semakin sedikit LOC semakin baik. Untuk plugin, kita dapat dengan mudah mengatakan bahwa plugin atau sebagian darinya adalah eksperimental.

IMO, plugin penyimpanan tidak boleh bergantung pada plugin lain.

Namun, kesimpulan ini belum diterima secara luas (@sanssecours?) atau didokumentasikan.

Sejauh yang saya tahu, tidak ada tempat dalam dokumentasi yang menyatakan bahwa plugin penyimpanan tidak boleh bergantung pada plugin lain. Saya juga tidak berpikir itu bagus dari sudut pandang pemisahan keprihatinan. Menulis plugin penyimpanan yang baik sudah cukup banyak pekerjaan menurut saya. Mengharuskan plugin penyimpanan menangani konversi jenis, kunci direktori, dan data biner (pengkodean Base64) tidak membuat pekerjaan itu lebih mudah.

Saya juga tidak berpikir itu bagus dari sudut pandang pemisahan keprihatinan. Menulis plugin penyimpanan yang baik sudah cukup banyak pekerjaan menurut saya.

Itulah gunanya perpustakaan pembantu. Ini membagi kode umum dan dengan demikian memberikan (beberapa) pemisahan masalah serta membuat pengembangan plugin lebih mudah.

Mengenai kekhawatiran @ markus2330 bahwa mengembangkan perpustakaan tujuan umum lebih sulit daripada plugin serupa: Itu sebenarnya salah, karena Anda dapat dengan mudah memberikan versi yang sedikit dimodifikasi dari fungsi elektraTypeGet saat ini sebagai perpustakaan. Modifikasi hanya diperlukan karena kita perlu mengganti Plugin * handle dengan KeySet * config . Meskipun ini mungkin tidak menyelesaikan semua masalah, setidaknya memungkinkan plugin penyimpanan mengontrol dengan tepat bagaimana dan kapan jenis barang selesai.

Sebagai contoh, toml dapat memiliki mode fallback INI di mana ia tidak menggunakan sistem tipe TOML tetapi sebaliknya beralih ke type dan mode TOML normal yang menyediakan elektraTypeGet dengan konfigurasi yang sangat tepat yang memastikan semuanya sesuai dengan spesifikasi TOML.

Singkatnya, perpustakaan sederhana jauh lebih fleksibel daripada plugin dari tampilan plugin penyimpanan. Setidaknya dengan kemungkinan konfigurasi plugin saat ini.

Mengharuskan plugin penyimpanan menangani konversi jenis, kunci direktori, dan data biner (pengkodean Base64) tidak membuat pekerjaan itu lebih mudah.

Mari kita uraikan ini:

• Data biner: Sebenarnya tidak ada upaya untuk melakukan sesuatu seperti:
  if (keyIsBinary (key)) { writeValue (elektraBase64Encode (keyValue (key), keyGetValueSize (key))); } else { writeValue (keyString (value)); }
  Plugin terpisah juga akan berfungsi, selama plugin penyimpanan dapat menegakkan bahwa plugin lain dipasang dalam semua keadaan dan dapat dengan mudah mengasumsikan tidak ada kunci biner. Jika plugin masih harus memanggil keyIsBinary dan menimbulkan kesalahan, solusi ini tidak ada manfaatnya. Saya juga tidak suka bahwa plugin biner terpisah harus mengonversi seluruh KeySet sekaligus, karena semua kunci Base64 membuang cukup banyak memori.
• Kunci direktori: Pertama, kunci non-daun dengan nilai ini aneh di hampir semua keadaan dan kami benar-benar harus merekomendasikan agar mereka dihindari. Ketika berurusan dengan kunci-kunci ini, seperti yang dinyatakan dalam #3256, saya pikir perpustakaan jauh lebih cocok untuk kasus ini. Ada banyak alasan, termasuk memori dan pemrosesan overhead, konfigurasi mountpoint yang rumit dan fleksibilitas yang tidak perlu. Sepertinya @ markus2330 (agak) setuju dengan saya dalam hal ini.
• Jenis: Setiap plugin penyimpanan untuk format yang memiliki sistem tipe asli harus melakukan setidaknya beberapa pekerjaan untuk tipe. Ini bisa berkisar dari melakukan konversi penuh dari awal hingga memanggil beberapa perpustakaan hingga mengonfigurasi plugin lain. Tidak akan pernah mungkin semuanya berjalan begitu saja. Bahkan jika a memiliki spesifikasi formal yang sangat rinci untuk tipe sehingga tidak diperlukan konfigurasi langsung dari plugin tipe, plugin penyimpanan harus mengimplementasikan spesifikasi ini dalam beberapa cara.

Namun, itu tidak memeriksa apakah nilai desimal/ganda over-/underflow long_long/double, jadi saya pikir itu dilakukan oleh typeplugin.

Ok, jadi pada dasarnya Anda hanya menggunakannya untuk memeriksa.

Tetapi dalam hal ini plugin terpisah juga bukan solusinya

Tidak, plugin terpisah sayangnya bukan solusi. Kami gagal di sana. Solusi saat ini adalah setiap plugin penyimpanan mengimplementasikan semuanya (kecuali penanganan biner) berdasarkan doc/tutorials/storage-plugins.md

Tetapi pengguna mungkin berharap bahwa kdb set /some/key/mounted/with/toml true akan berfungsi.

Tidak, pengguna seharusnya tidak mengharapkan itu. Dalam Elektra 1/0 benar/salah. Hanya plugin penyimpanan yang dapat memetakan ini ke sesuatu yang lain.

Dasar Pemikiran: Karena setidaknya pada level spesifikasi hanya 1/0 yang berfungsi, itu hanya akan membingungkan untuk membuat true/false berfungsi di tempat lain (dengan pengecualian plugin penyimpanan).

Ini hanya menunjukkan bahwa plugin penyimpanan HARUS dapat menangani semua jenis yang didukung oleh format penyimpanan dan konversi terkait TANPA menggunakan plugin lain.

Ya saya setuju.

Itu adalah poin yang adil, meskipun saya tidak berpikir hanya menghapus kode adalah solusi yang tepat.

Tentu saja kami perlu menghapus kode yang "benar": kode yang memberi Anda harapan tanpa memenuhinya atau menimbulkan masalah dengan bagian lain dari Elektra. Dan beberapa fungsi dari jenis plugin tampaknya membuat masalah bersama dengan bagian lain dari Elektra.

Setidaknya tidak ketika datang ke plugin. Dalam inti, saya setuju, semakin sedikit LOC semakin baik. Untuk plugin, kita dapat dengan mudah mengatakan bahwa plugin atau sebagian darinya adalah eksperimental.

Sayangnya, ini tidak berhasil (belum*). Orang tidak menilai status plugin dengan benar, misalnya baru-baru ini lihat: #3472 di mana plugin INI yang tidak dirawat dan dipenuhi bug, dan lebih buruk lagi, plugin xmltool lawas yang tidak disarankan, diyakini bekerja dengan sempurna.

• Mungkin bekerja lebih baik jika saya mengerjakan ulang #666 dan kami mengeluarkan peringatan selama pemasangan.

Mengharuskan plugin penyimpanan menangani konversi jenis, kunci direktori, dan data biner (pengkodean Base64) tidak membuat pekerjaan itu lebih mudah.

@sansecours bagaimana plugin YAML menangani konversi tipe?

Itu salah secara faktual

Kita lihat saja kalau sudah selesai :stuck_out_tongue_winking_eye:

Singkatnya, perpustakaan sederhana jauh lebih fleksibel daripada plugin dari tampilan plugin penyimpanan. Setidaknya dengan kemungkinan konfigurasi plugin saat ini.

Tidak ada yang berdebat tentang itu. Tetapi fleksibilitas terkadang datang dengan harga yang mahal.

Sebenarnya tidak ada upaya apa pun yang terlibat dalam melakukan sesuatu seperti

base64 bukan satu-satunya cara untuk mengkodekan data biner. Untuk standar di mana base64 diperlukan, itu bisa dikodekan secara keras. ( @sanssecours Apakah ini berlaku untuk YAML?)

Namun untuk TOML, ia hanya mengatakan "Base64 atau pengkodean ASCII atau UTF-8 lain yang sesuai", sehingga plugin biner lainnya dapat digunakan. Jadi solusi saat ini memiliki kelebihan, karena pengguna dapat memasang plugin biner lainnya sesuai keinginan atau kebutuhan.

@bauhaus93 - infos/needs = base64 harus diubah menjadi - infos/needs = binary .

Pertama, kunci non-daun dengan nilai ini aneh di hampir semua keadaan dan kami benar-benar harus merekomendasikan agar mereka dihindari.

Ada sangat umum dalam banyak format. Dan mereka bisa sangat berguna saat Anda memperluas spesifikasi (membuat subkunci dari kunci yang memiliki nilai).

[Kunci direktori] Sepertinya @ markus2330 (agak) setuju dengan saya dalam hal ini.

Saya setuju plugin penyimpanan perlu menanganinya (mungkin dengan perpustakaan tetapi tidak dengan plugin "nilai direktori" karena pelolosan tidak berfungsi dan pelolosan yang benar adalah salah satu pekerjaan utama plugin penyimpanan).

Ok, jadi pada dasarnya Anda hanya menggunakannya untuk memeriksa.

Saya tidak setuju dengan ungkapan "plugin toml menggunakan plugin type ". Dalam versi saat ini hanya merekomendasikan type .

https://github.com/ElektraInitiative/libelektra/blob/c61e388c4aa950cf84aa2f00fba7cdd34a47640e/src/plugins/toml/README.md#L5 -L6

Bahkan jika type dideklarasikan sebagai needs , saya tidak akan menyebutnya "menggunakan". toml tidak benar-benar memiliki kontrol langsung atas type . Itu sebabnya saya mengatakan toml bergantung pada type . Ia mengharapkan type melakukan hal-hal tertentu dengan cara tertentu, tetapi saya tidak dapat melakukan apa pun, jika bukan itu masalahnya.

Mungkin bekerja lebih baik jika saya mengerjakan ulang #666 dan kami mengeluarkan peringatan selama pemasangan.

Saya setuju. Mungkin bahkan pada setiap kdbGet juga, kecuali jika kunci khusus "Saya mengakui titik mount ini menggunakan plugin eksperimental" telah disetel.

base64 bukan satu-satunya cara untuk mengkodekan data biner.

Itu sebenarnya argumen untuk plugin binary . Meskipun saya masih menginginkan antarmuka di mana plugin dapat bekerja dengan satu kunci pada satu waktu, ini dapat mencapai beberapa penghematan memori dan mungkin juga penghematan kinerja. (Tapi itu masalah lain)

Ada sangat umum dalam banyak format.

Apakah kamu punya contoh?

Dan mereka bisa sangat berguna saat Anda memperluas spesifikasi (membuat subkunci dari kunci yang memiliki nilai).

Benar, tetapi dalam hal ini saya akan merekomendasikan solusi "salah satu atau" (dari POV pengguna akhir). Entah Anda menggunakan kunci lama dengan nilai tunggal, atau Anda menggunakan versi baru dengan subkunci. Kalau tidak, konfigurasi mungkin akan membingungkan.

Untuk lebih jelasnya, saya tidak berpikir kunci non-daun dengan nilai tidak boleh digunakan, tetapi mereka harus dihindari jika memungkinkan dan jarang (jika pernah) adalah solusi yang disukai.

tetapi tidak dengan plugin "nilai direktori" karena melarikan diri tidak berfungsi

Di #3256 saya menyarankan penggunaan metadata untuk memecahkan masalah melarikan diri. Juga ada ide-ide saya dari #3223 yang akan menyelesaikan masalah pelarian (untuk setiap kasus penggunaan tidak hanya directoryvalue ) serta beberapa hal lainnya. Lihat juga proposal (sangat formal) . Saya akan menambahkan penjelasan bahasa Inggris hari ini atau besok ke dokumen itu, karena saya masih sangat mendukung perubahan ini.

@sansecours bagaimana plugin YAML menangani konversi tipe?

Yan LR dan YAML CPP menggunakan plugin type untuk boolean. YAML CPP juga menggunakan plugin base64 untuk data biner.

base64 bukan satu-satunya cara untuk mengkodekan data biner. Untuk standar di mana base64 diperlukan, itu bisa dikodekan secara keras. ( @sanssecours Apakah ini berlaku untuk YAML?)

Ya, sejauh yang saya tahu data biner di YAML selalu menggunakan pengkodean Base64.

[kunci non-daun dengan nilai] Apakah Anda punya contoh?

XML dan sebagian besar dialek INI (karena memungkinkan key=value bahkan ketika [key] ada)

Benar, tetapi dalam hal ini saya akan merekomendasikan solusi "salah satu atau" (dari POV pengguna akhir). Entah Anda menggunakan kunci lama dengan nilai tunggal, atau Anda menggunakan versi baru dengan subkunci. Kalau tidak, konfigurasi mungkin akan membingungkan.

Ya, itu terdengar masuk akal. Setelah Anda mengetahui sesuatu adalah bagian, Anda biasanya memindahkan nilainya ke suatu tempat di dalam bagian tersebut.

Misalnya deluser.conf memiliki BACKUP = 0 dan BACKUP_TO = "." . Dengan bagian, sebagian besar aplikasi akan menggunakan BACKUP_ENABLE bukan hanya BACKUP .

Juga ada ide saya dari #3223 yang akan menyelesaikan masalah pelarian (untuk setiap kasus penggunaan tidak hanya directoryvalue ) serta beberapa hal lainnya.

Sekarang saya telah memperbarui proposal di #3223. Saya harap sekarang lebih mudah dipahami (masih sangat panjang).

https://github.com/kodebach/libelektra/blob/dcec6e865bba32f6d83c40c2f711c2e70dde6d62/doc/proposals/keynames.md

Pertanyaan besarnya adalah siapa yang akan mengimplementasikan semua ini. Hal ini cukup jauh dari status quo, yaitu, banyak pekerjaan (hanya perubahan terminologi adalah sejumlah besar pekerjaan). Jika Anda ingin menerapkannya, Anda dapat membuat PR dengan proposal dan saya mengomentarinya. Jika tidak, kita harus mundur selangkah dan memikirkan solusi yang layak dalam jangkauan kita.

Omong-omong. bagian pertama dari proposal sebenarnya adalah tutorial yang bagus tentang cara kerja nama-nama kunci. Akan luar biasa untuk memiliki ini sebagai tutorial. :sparkling_heart:

Pertanyaan besarnya adalah siapa yang akan mengimplementasikan semua ini.

Itu selalu menjadi pertanyaan...

Hal ini cukup jauh dari status quo, yaitu, banyak pekerjaan (hanya perubahan terminologi adalah sejumlah besar pekerjaan).

Perubahan terminologi jelas merupakan bagian terbesar, terutama mengubah semua dokumentasi. Namun, ini tidak harus dilakukan oleh satu orang. Perubahan ini cukup sederhana, hanya membosankan, sehingga siapa pun dapat membantu, bahkan tanpa pengetahuan yang luas tentang kode tersebut. Untuk sebagian besar itu hanya berarti membaca semua dokumentasi dan mengganti kemunculan hal-hal seperti "nama dasar".

Jika Anda ingin menerapkannya, Anda dapat membuat PR dengan proposal dan saya mengomentarinya. Jika tidak, kita harus mundur selangkah dan memikirkan solusi yang layak dalam jangkauan kita.

Saya akan memulai PR, tetapi apakah saya punya waktu untuk menyelesaikannya (sendirian) dalam waktu dekat, saya tidak bisa mengatakannya.
Saya sudah memiliki cabang lokal di mana semua panggilan ke keyBaseName , keySetBaseName dan keyAddBaseName telah digantikan oleh keyLastUnescapedPart , keySetLastUnescapedPart / keySetLastLiteralPart dan keyAddUnescapedPart / keyAddLiteralPart . Saya membuatnya menggunakan regex-replace semi-otomatis setelah saya menulis proposal pertama.

Tetapi di cabang itu fungsi baru hanya #define s untuk yang lama, jadi implementasi sebenarnya masih harus ditulis dan kemudian tes dan mungkin plugin penyimpanan harus diperbarui.

Masalah terbesar bagi saya adalah plugin penyimpanan. Saya dapat mengimplementasikan pembaruan ke inti dan pengujian dan mungkin satu plugin penyimpanan. Tapi saya lebih suka, jika saya tidak perlu mempelajari kode untuk semua plugin penyimpanan dan mencari tahu semua seluk-beluk semua format.

Omong-omong. bagian pertama dari proposal sebenarnya adalah tutorial yang bagus tentang cara kerja nama-nama kunci. Akan luar biasa untuk memiliki ini sebagai tutorial.

Makanya saya tulis begini. Rencana saya adalah menggunakan kembali bagian dari proposal ini untuk dokumentasi di #3447. Saya tidak dapat menggunakannya 1:1 karena saya meninggalkan beberapa bagian yang sangat penting (misalnya kanonik vs non-kanonik).

Saya harus berterus terang dan tidak memberi Anda harapan yang salah: Seperti yang Anda lihat di LCDproc, tidak terjadi bahwa orang lain melompat ke depan menyelesaikan tugas, terutama ketika mereka membosankan. PR yang menghancurkan semua plugin penyimpanan kecuali satu tidak dapat digabungkan. Dan plugin storage tidak banyak diuntungkan dari PR ini, malah “lebih parah” dalam artian tiba-tiba akan menghasilkan kesalahan sintaks pada file yang bisa mereka parsing sekarang. Ini tidak berarti itu adalah ide yang buruk secara keseluruhan. Dengan beberapa penyempurnaan, ini mungkin lebih baik daripada status-quo, tetapi saya tidak melihat bagaimana kami dapat melakukan tugas besar seperti itu dengan begitu banyak tugas terbuka penting lainnya yang kami miliki saat ini.

Jadi tolong biarkan kami berkonsentrasi pada #3447 (docu), akhirnya menyelesaikan #2969, meningkatkan plugin TOML dan topik penting lainnya yang kami butuhkan untuk 1.0 (https://github.com/ElektraInitiative/libelektra/milestone/12 dan https:// github.com/ElektraInitiative/libelektra/milestone/14). Setelah ini terlihat bagus, kita bisa melihat ide lain mana yang bisa kita capai.

Bagi saya kesimpulan dari diskusi ini adalah bahwa pasti ada kebutuhan perpustakaan untuk memudahkan menulis plugin penyimpanan karena pendekatan plugin tidak berfungsi (kecuali untuk biner terlihat). Kesimpulan ini harus ada dalam tutorial plugin penyimpanan.
@bauhaus93 dapatkah Anda mengambil tugas untuk melanjutkan tutorial plugin penyimpanan? Anda memiliki banyak wawasan sekarang, yang tidak dapat dilihat dengan melihat kode sumber dari plugin toml.

PR yang menghancurkan semua plugin penyimpanan kecuali satu tidak dapat digabungkan.

Saya tidak mengharapkan siapa pun untuk menggabungkan PR seperti itu... Saya hanya mengatakan akan lebih baik jika orang lain dapat membantu memperbarui plugin penyimpanan. Idealnya penulis asli plugin. Setelah #3491 beberapa plugin penyimpanan yang lebih kompleks akan dihapus, jadi seluruh tugas akan lebih mudah.

Dan plugin storage tidak banyak diuntungkan dari PR ini, malah “lebih parah” dalam artian tiba-tiba akan menghasilkan kesalahan sintaks pada file yang bisa mereka parsing sekarang.

Ini tidak seharusnya terjadi. Bahkan ada penjelasan parsial di akhir proposal . AFAIK seharusnya tidak ada kasus, di mana plugin penyimpanan harus menolak file, karena tidak dapat diterjemahkan ke dalam KeySet .

Satu-satunya pengecualian adalah format, yang secara langsung menggunakan Nama Kunci Elektra (escape atau unescaped). Ini mungkin menerima lebih sedikit file setelah proposal ini daripada sebelumnya. Tetapi karena sintaks untuk file-file ini selalu bergantung pada sintaks untuk Nama-Nama Kunci, ini sepenuhnya diharapkan.

Dengan beberapa penyempurnaan, ini mungkin lebih baik daripada status-quo, tetapi saya tidak melihat bagaimana kami dapat melakukan tugas besar seperti itu dengan begitu banyak tugas terbuka penting lainnya yang kami miliki saat ini.

Saya tidak pernah berharap proposal ini akan segera diadopsi. Tapi saya pikir kita harus mempertimbangkan untuk mengimplementasikannya sebelum 1.0. Setelah 1.0 dirilis, proposal akan menjadi perubahan besar. Saya tidak berpikir merilis versi 2.0 bahkan 1 atau 2 tahun setelah 1.0 (tidak lebih awal dari itu) akan menjadi ide yang baik, mengingat target audiens Elektra.

Jadi tolong biarkan kami berkonsentrasi pada #3447 (docu), akhirnya menyelesaikan #2969, meningkatkan plugin TOML dan topik penting lainnya yang kami butuhkan untuk 1.0

Saya sangat setuju. Tapi sekali lagi, kita tetap harus mempertimbangkannya, karena setelah 1.0 dirilis, menambahkan perubahan break akan sangat sulit untuk beberapa waktu.

Bagi saya kesimpulan dari diskusi ini adalah pasti perlu adanya perpustakaan untuk memudahkan menulis plugin penyimpanan

👍

kecuali untuk biner harus dilihat

IMO, kasus nilai biner sangat berbeda. Ini adalah terjemahan nilai kunci 1:1, seperti banyak lainnya ( rgbcolor , macaddr , ipaddr , dll), jadi sebuah plugin sebenarnya sangat cocok di sini. Namun, seperti yang saya katakan, API plugin baru yang menangani hanya satu kunci pada satu waktu bisa menjadi peningkatan. Tapi itu dapat dengan mudah ditambahkan pasca-1.0 karena itu tidak akan menjadi perubahan besar jika dilakukan dengan benar.

kebanyakan -> harus?

Ya, saya melihatnya dengan cara yang sama: tidak realistis bahwa perubahan ini akan terjadi setelah 1.0 keluar (seluruh tujuan 1.0 adalah untuk membekukan keputusan seperti itu sehingga orang lain dapat mengandalkannya) dan akan menyenangkan untuk memiliki peningkatan seperti itu sebelumnya . Tetapi seperti yang dikatakan: kita benar-benar perlu berkonsentrasi untuk menyelesaikan hal-hal penting dan tidak kehilangan energi kita dalam pertempuran yang menyenangkan yang tidak dapat kita menangkan dengan kekuatan manusia kita saat ini.