Libelektra: Karakter yang Dicadangkan dalam Nama Kunci

Lihat juga # 2698 untuk diskusi karakter mana yang akan digunakan untuk array (globbing)

Pertama-tama, jika Anda mencantumkan \ , Anda juga harus memasukkan / pada daftar. Garis miring jelas merupakan prototipe karakter cadangan (karakter dengan arti khusus) di Elektra.

Kedua, "digunakan untuk globbing" dan "digunakan untuk merujuk ke parentKey, misalnya dalam plugin kondisional" bukan kasus penggunaan yang valid di sini. Ini bukan arti khusus selama membuka kunci. Jika Anda ingin mencegah interpretasi khusus yang terjadi kemudian (misalnya oleh plugin atau library), Anda harus tahu bahwa interpretasi ini didasarkan pada nama kunci yang di-escape (yang akan berakibat buruk, seperti yang dijelaskan di https: // github. com / ElektraInitiative / libelektra / issues / 2698 # Issuecomment-554636250), atau Anda harus memastikan bahwa nama yang tidak di-escape tidak dapat diinterpretasikan secara khusus.

Mari kita ambil # sebagai contoh. Perpustakaan globbing kami mengartikan nama kunci /a/# sebagai arti "cocok dengan elemen array apa pun dalam array /a ". Jika kita tidak menginginkannya, tetapi ingin mencocokkan /a/# secara harfiah, kita perlu menggunakan semacam pelarian. Namun, /a/\# tidak dapat berfungsi. Apa yang dicapai garis miring terbalik selama membuka nama kunci? Untuk mencegah interpretasi khusus perpustakaan globbing, itu harus tetap di sana selama membuka. Tapi itu melanggar aturan (°) bahwa garis miring terbalik harus di-escape, jika itu bukan karakter escape itu sendiri (bukan karakter escape, jika tidak menghilang selama unescaping). Jadi kita perlu menggunakan /a/\\# , yang akan dihilangkan menjadi ⊙a⊙\# (⊙ di tempat NUL, namespace dan terminator dihilangkan). Tetapi dalam kasus itu # tidak memiliki arti khusus untuk membuka kunci nama kunci dan tidak harus dipertimbangkan sama sekali.

Dengan kata lain, untuk memberikan alasan mengapa karakter harus melarikan diri (mengapa dicadangkan), Anda harus memikirkan tentang _ "Perilaku apa dari elektraKeyNameCanonicalize atau elektraKeyNameUnescape akan mencegah lolos?" _ .

Untuk karakter yang sebenarnya ingin kita buat "pendiam", ada keputusan yang harus kita buat disini. Apakah _karakter ini dengan arti_ khusus atau _karakter yang disimpan_ sebenarnya_?

Dalam pikiran saya, _characters with special meaning_ adalah karakter normal yang dapat digunakan seperti itu, tetapi mungkin memiliki interpretasi khusus dalam konteks tertentu (misalnya % jika itu adalah keseluruhan bagian kunci).

_Karakter yang disimpan_ di sisi lain disediakan untuk konteks khusus. Mereka tidak dapat digunakan secara normal dan hanya diperbolehkan dalam konteks khusus, di mana mereka memiliki arti khusus.

Karakter _karakter dengan arti khusus_ hanya harus dilepaskan dalam konteks yang memiliki interpretasi khusus, jika interpretasi khusus ini tidak diinginkan. Di luar konteks ini, melarikan diri mungkin diperbolehkan atau tidak, tergantung pada pendirian kita tentang melarikan diri yang tidak perlu (° °).

Karakter _reserved_ di sisi lain harus di -escape setiap kali tidak memiliki arti khusus. Artinya, dalam konteks di mana ia memiliki makna khusus, ia dapat diloloskan, untuk menghindari makna khusus tersebut. Di luar konteks ini, harus di -escape.

Sebagai contoh, mari kita lihat % . Jika seluruh bagian kunci hanya % (misalnya /%/ ), bagian ini tidak akan lolos ke bagian kosong. Dalam kedua kasus, garis miring terbalik di /\%/ akan mencegah interpretasi khusus dan itu akan terhapus ke bagian yang % . Perbedaannya menjadi terlihat, bagaimanapun, jika melihat konteks yang berbeda, seperti /a%b/ .

Jika kita memperlakukan % sebagai _reserved character_, maka /a%b/ adalah nama / bagian kunci yang tidak sah dan kita harus membuat kesalahan. Cara yang benar untuk mencapai bagian yang tidak lolos a%b dengan karakter _reserved_ akan menggunakan /a\%b/ .

Jika kita melihat % sebagai _character dengan arti khusus_, maka /a%b/ akan benar dan terhapus menjadi a%b . Sekali lagi, apakah /a\%b/ juga diperbolehkan, tergantung pada pendirian kita tentang pelarian yang tidak perlu. Jika diizinkan, ini juga akan berubah menjadi a%b .

Catatan: Untuk / tidak ada keputusan, kedua interpretasi sama, karena tidak ada konteks, di mana / tidak memiliki arti khusus. Untuk \ kami telah memutuskan (di # 3115) untuk memperlakukannya sebagai karakter _reserved_ dan oleh karena itu memerlukan pelolosan, ketika itu tidak digunakan sebagai karakter pelarian itu sendiri.

Keputusan atas tentunya juga menuntut kita untuk mendefinisikan, di mana konteks dapat karakter ini, sekarang atau di masa depan, memiliki arti khusus.

Ada dua solusi mudah di sini:
Perlakukan semuanya (kecuali / dan \ ) sebagai _characters dengan arti khusus_, izinkan pelolosan yang tidak perlu dan untuk yang tidak digunakan tentukan bahwa memiliki interpretasi khusus dalam semua konteks. Interpretasi khusus untuk ini adalah bahwa mereka membuat nama kunci ilegal. Oleh karena itu, yang tidak terpakai harus selalu diloloskan. Lain dari daftar karakter selalu dapat melarikan diri, tetapi hanya harus, jika kita ingin mencegah interpretasi khusus tertentu.

---

(°) Seperti yang dinyatakan di # 3115, aturan ini membuat keseluruhan sistem jauh lebih mudah untuk dipahami. Dalam nama kunci yang di-escape (valid), garis miring terbalik selalu mengesampingkan sesuatu. Dalam nama kunci yang tidak lolos (valid), garis miring terbalik selalu secara harfiah merupakan garis miring terbalik.

(° °) Jika kita mengadopsi sikap yang sangat ketat pada pelarian yang tidak perlu, itu harus memungkinkan untuk mendapatkan hubungan 1: 1 antara nama kunci yang diloloskan dan tidak di-escape. Ini tentu saja membutuhkan lebih banyak usaha dalam memvalidasi nama kunci dan oleh karena itu akan berdampak pada kinerja (apakah dampak ini signifikan harus diuji).

Pertama-tama, jika Anda mendaftar \, Anda juga harus meletakkan / pada daftar. Garis miring jelas merupakan prototipe karakter cadangan (karakter dengan arti khusus) di Elektra.

Terima kasih, saya menambahkannya. Jika Anda menemukan karakter lain, Anda dapat menambahkannya ke postingan teratas.

Kedua, "digunakan untuk globbing" dan "digunakan untuk merujuk ke parentKey, misalnya dalam plugin kondisional" bukan kasus penggunaan yang valid di sini. Ini bukan arti khusus selama membuka kunci.

Ya, tentu saja kita juga dapat menggunakan satu atau dua karakter escape lain \ untuk beberapa karakter ini. Tapi ini akan lebih rumit bagi pengguna?

Apa yang dicapai garis miring terbalik selama membuka nama kunci?

Saya berpikir bahwa keyAddBaseName (key, "_") sebenarnya akan menambahkan \_ . Jadi untuk mendapatkan _ (dengan arti karakter globbing), Anda perlu menggunakan keyAddName.

Misalnya @sanssecours saat ini sebenarnya menggunakan _ di dalam nama kunci untuk plugin directoryvalue. Tentu saja tidak ada cara untuk menghindarinya, karena mesin pelarian semacam itu tidak sepele untuk ditulis. Saya berharap kami dapat memiliki satu tempat untuk melaksanakan pelarian semacam itu.

Untuk karakter yang sebenarnya ingin kita buat "pendiam", ada keputusan yang harus kita buat disini. Apakah karakter ini memiliki arti khusus atau karakter cadangan yang sebenarnya?

Jika mereka tidak memiliki arti khusus sekarang, mereka disimpan sehingga kami dapat memberi mereka arti khusus nanti. Kami tidak dapat "memesan" atau "memberikan arti khusus" di lain waktu, karena aplikasi mungkin sudah menggunakan karakter tersebut.

Untuk memperjelas: Di posting atas, "arti khusus" dan "dicadangkan" adalah sinonim untuk mesin pelarian. Dan saya akan menyimpannya sebagai sinonim untuk membuat pelarian lebih mudah.

Karakter cadangan di sisi lain disediakan untuk konteks khusus. Mereka tidak dapat digunakan secara normal dan hanya diperbolehkan dalam konteks khusus, di mana mereka memiliki arti khusus.

Untuk membuat seluruh mesin pelarian ini waras, saya hanya akan berasumsi bahwa karakter khusus selalu istimewa, kecuali saat mereka lolos.

Secara khusus, saya ingin menghindari situasi di mana karakter mendapatkan makna khusus jika karakter pelarian ditambahkan. Ini adalah peretasan yang buruk dan membuat misalnya regex menjadi tidak perlu rumit.

Jika kita melihat% sebagai karakter dengan arti khusus, maka / a% b / akan benar dan tidak berubah menjadi% b.
Sekali lagi, apakah / a% b / juga diperbolehkan, tergantung pada pendirian kita tentang pelarian yang tidak perlu. Jika dibiarkan, ia juga berubah menjadi% b.

Persis. Mesin tidak dapat sepenuhnya mencegah pembuatan nama dengan arti yang salah. Jadi saya pikir kita sebaiknya tidak mencoba melakukannya. Misalnya,% di tempat penampung harus memiliki jumlah kejadian genap tetapi ada pengecualian. Dan mungkin beberapa perluasan nilai kontekstual akan menambah pengecualian lebih lanjut.

Jika kita mengadopsi sikap yang sangat ketat pada pelolosan yang tidak perlu, seharusnya dimungkinkan untuk mendapatkan hubungan 1: 1 antara nama kunci yang diloloskan dan tidak di-escape. Ini tentu saja membutuhkan lebih banyak usaha dalam memvalidasi nama kunci dan oleh karena itu akan berdampak pada kinerja (apakah dampak ini signifikan harus diuji).

Saya pikir tujuan kita yang paling penting adalah bahwa pelarian itu mudah dipahami dan digunakan. Pelarian sebelumnya berusaha keras agar setiap nama valid. Tujuan seperti itu kebanyakan menyebabkan sakit kepala tetapi sebenarnya tidak meningkatkan kegunaan. Jika seseorang menempatkan \ di tempat yang sewenang-wenang, Anda boleh menolak beberapa nama. Tetapi di depan karakter khusus, \ harus selalu valid dan menghilangkan arti khusus (masa depan).

Saya berpikir bahwa keyAddBaseName (key, "_") sebenarnya akan menambahkan \_ . Jadi untuk mendapatkan _ (dengan arti karakter globbing), Anda perlu menggunakan keyAddName.

Ini sangat membingungkan saya ...

Semantik dari keyAddBaseName (Key * key, const char * x) adalah:
x adalah bagian yang tidak lolos . Ini akan ditambahkan langsung ke akhir key->ukey . Bentuk pelolosannya akan ditambahkan ke akhir key->key .

Semantik dari keyAddName (Key * key, const char * x) adalah:
x adalah sufiks nama yang di- escape (misalnya, nol atau lebih bagian, tidak ada namespace). Ini akan dikanonikalisasi dan ditambahkan ke akhir key->key . Formulir yang tidak lolos akan ditambahkan ke akhir key->ukey .

Sekarang, Anda ingin keyAddBaseName (key, "_") menambahkan bagian \_ ke nama yang di-escape dan, bagian _ ke nama yang tidak di-escape. Dan itu seharusnya tidak berdampak pada globbing. Tapi keyAddName (key, "_") seharusnya memiliki arti untuk globbing, jadi apa fungsinya? _ tidak bisa dihilangkan dengan cara apapun, itu hanya satu karakter. Jadi kita harus menambahkan _ ke nama yang di-escape dan tidak di-escape. Namun kedua versi tersebut menghasilkan nama unescaped yang sama, yang berarti harus memiliki arti yang sama untuk globbing ...

saat ini sebenarnya menggunakan _ di dalam nama kunci untuk plugin nilai direktori.

AFAIK directoryvalue hanya menggunakan bagian kunci /__directoryvalue/ . Ini sama sekali tidak bertabrakan dengan penggunaan globbing dari /_/ .

Kami tidak dapat "memesan" atau "memberikan arti khusus" di lain waktu, karena aplikasi mungkin sudah menggunakan karakter tersebut.

Ini hanya akan menjadi perubahan besar, seperti yang kami lakukan pada nama-nama kunci sekarang.

Saya pikir kita perlu membedakan dua hal:

1. Karakter yang memiliki arti khusus untuk keySetName (atau lebih tepatnya elektraKeyNameCanonicalize dan elektraKeyNameUnescape ).
2. Karakter yang memiliki arti khusus untuk plugin, library, atau bagian lain dari Elektra yang tidak terkait dengan manipulasi nama kunci.

Grup pertama akan menjadi beberapa bentuk karakter yang dicadangkan, penggunaan yang tidak tepat akan mengakibatkan keySetName gagal (dan keyNew akan mengembalikan NULL ). Di sinilah melarikan diri dengan garis miring terbalik membantu, karena garis miring terbalik memberi tahu keySetName untuk mengambil karakter berikut secara harfiah dan mengabaikan makna apa pun yang mungkin dimilikinya.

Kelompok kedua sama sekali berbeda. Tidak ada yang bisa kita lakukan selama keySetName (atau keyAddName , keyAddBaseName , dll.) Untuk mengubah apakah karakter grup ini memiliki arti khusus untuk beberapa plugin atau tidak. Ini sepenuhnya terserah plugin untuk memutuskan itu dan segala bentuk pelolosan plugin mungkin memungkinkan untuk mencegah arti khusus harus membuatnya ke plugin. Perlu diingat, bahwa kami mengatakan keySetName gagal dan keyNew mengembalikan NULL untuk nama yang tidak valid. Dalam keySetName
kita tidak bisa misalnya mengatakan /# memiliki arti khusus, /#a tidak diperbolehkan, tetapi /\# tidak memiliki arti khusus /\#a diperbolehkan. Kami tidak tahu, bagaimana ini akan digunakan. Jika kami melarang beberapa kunci, tidak ada plugin yang dapat menggunakannya. (Catatan: pada paragraf di atas: plugin = plugin, library, application, dll.)

Jika Anda benar-benar ingin menyatukan ketika sesuatu dapat memiliki arti khusus untuk plugin / pustaka, saya hanya dapat melihat sesuatu seperti ini berfungsi:

Tentukan beberapa aturan pelolosan untuk % , . , / dan \ , sebagai pengaruh keySetName . Lakukan hal-hal indeks array dari # 2698. Bagian nama kunci (lolos dan tidak lolos) dimulai dengan @ harus dalam bentuk (regex) @[^@]+@.+ . Karakter @ mungkin tidak muncul dalam konteks lain. Segala sesuatu yang lain tidak memiliki arti khusus selama keySetName dan dapat digunakan tanpa batasan. Plugin, pustaka, dll. MUNGKIN TIDAK mengatribusikan arti khusus untuk setiap karakter atau bagian nama kunci kecuali, ke bagian nama kunci yang tidak lolos yang dimulai dengan @ . Bagian nama kunci yang tidak lolos dari formulir (regex) @[^@]+@.+ hanya dapat memiliki arti khusus untuk plugin yang dinamai oleh [^@] bagian dari regex. Apa artinya, terserah plugin dan ditentukan oleh bagian setelah @ .

Saya menyadari bahwa ini sama sekali berbeda dari pendekatan saat ini dan sama sekali tidak masuk akal untuk diterapkan, jika kami ingin merilis 1.0 dalam waktu dekat, tetapi ini adalah satu-satunya pendekatan yang berfungsi yang dapat saya lihat, yang memungkinkan kami untuk secara definitif mengatakan apakah bagian kunci memiliki arti khusus atau tidak.

Saya pikir kita perlu membedakan dua hal:

Harapan saya adalah bahwa kita dapat membuang perbedaan ini agar pelarian keseluruhan lebih mudah dipahami. Kemudian keyAddBaseName tidak pernah menambahkan sesuatu yang memiliki arti pada Elektra.

Jika ini tidak memungkinkan, persyaratan minimumnya adalah dimungkinkan untuk meneruskan string apa pun ke keyAddBaseName dan mendapatkan kembali string yang sama saat menanyakan nama dasar dengan keyBaseName , lihat # 2698.

Ya, itu akan merusak beberapa kejadian keyAddBaseName dimana nama array ditambahkan. Tetapi itu akan merusak beberapa kasus, karena sekarang tidak setiap nama array valid, jadi kita perlu memecahkan beberapa kode:

1. kode yang mengasumsikan setiap string dapat disetel atau
2. kode yang diasumsikan array dapat ditambahkan.

Sangat jelas bagi saya bahwa kita tidak boleh merusak 1., yaitu kode yang mengasumsikan setiap string dapat diteruskan ke keyAddBaseName . "2." tidak begitu penting, ini adalah beberapa kejadian yang bisa diperbaiki.

Contoh lain di samping SSID: entri fstab pada dasarnya dapat memiliki segalanya termasuk /. Atau nama titik gunung di Elektra.

Kemudian keyAddBaseName tidak pernah menambahkan sesuatu yang memiliki arti ke Elektra.

Saya melihat sekarang bahwa ini sekali lagi datang menyelesaikan masalah utama di jantung Elektra. Semuanya harus koheren dan sistem yang terdefinisi dengan baik, tetapi pada saat yang sama semuanya harus fleksibel dan plugin harus digunakan sebanyak mungkin. Ini tidak bisa berhasil.

Masalahnya secara khusus adalah frasa "artinya Elektra". Kita dapat memastikan keyAddBaseName tidak pernah menambahkan sesuatu yang memiliki arti ke elektra-core , atau dalam istilah yang lebih jelas, bahwa keyAddBaseName menambahkan argumennya sebagai bagian nama kunci yang tidak dapat dihilangkan. Tetapi untuk aplikasi "Elektra" juga berarti semua plugin Elektra. Dalam interpretasi itu, menjadi sangat sulit untuk mencegah keyAddBaseName menambahkan sesuatu yang "memiliki arti". Plugin apa pun dapat memutuskan untuk mengatribusikan arti ke nama kunci yang tidak lolos kapan pun. Seperti yang saya katakan, satu-satunya solusi adalah memperkenalkan sistem yang sangat ketat, seperti yang diusulkan di atas dengan @ . Jika Anda menemukan sesuatu yang berbeda, beri tahu saya, tetapi untuk semua yang saya temukan sampai tahu, saya menemukan masalah.

Sangat jelas bagi saya bahwa kita tidak boleh merusak 1., yaitu kode yang mengasumsikan setiap string dapat diteruskan ke keyAddBaseName

Mengapa? Semuanya jelas bagi saya, mengapa ini lebih disukai? Nama file UNIX misalnya tidak boleh mengandung / dan tidak ada yang mengira itu masalah. (Tidak mengizinkan / membuat pemisahan jalur UNIX menjadi beberapa bagian jauh lebih sederhana daripada dengan nama kunci).

Kami telah memecahkan (hampir) SETIAP bagian kode yang berinteraksi dengan Elektra dengan menambahkan : setelah namespace. Pada keadaan saat ini, hanya kunci bertingkat tanpa bagian array apa pun dan juga mengecualikan beberapa karakter khusus lainnya yang akan terus berfungsi tanpa memerlukan perubahan. Kompatibilitas mundur sudah lama di luar jendela.

"2." tidak begitu penting, ini adalah beberapa kejadian yang bisa diperbaiki.

Saya tidak terlalu yakin tentang itu. Sebenarnya saya tahu hanya satu bagian Elektra yang benar-benar mengasumsikan bahwa keyAddBaseName lolos dari segalanya dan itu adalah elektra-kdb dan alat-alat yang membuat mountpoint.

Entri fstab pada dasarnya dapat memiliki segalanya termasuk /

Tidak yakin mengapa itu relevan?

Atau nama titik gunung di Elektra.

Untuk membuat mountpoint user:/my/mount alat meletakkan konfigurasi mountpoint di bawah system:/elektra/mountpoints/user:\/my\/mount , tetapi bisa juga menggunakan kunci unik lainnya langsung di bawah system:/elektra/mountpoints , karena mountpoint sebenarnya adalah nilai misalnya system:/elektra/mountpoints/user:\/my\/mount/mountpoint . AFAICT system:/elektra/mountpoints mungkin juga sebuah array. Saya belum menemukan tempat yang memanggil keyBaseName pada kunci tepat di bawah system:/elektra/mountpoints .

Mungkin ada beberapa tempat yang menggunakan mountGetMountpoint atau mountGetBackend untuk mendapatkan mountpoint dan merekonstruksi system:/elektra/mountpoints/user:\/my\/mount/ untuk mengakses beberapa konfigurasi, tetapi itu dapat dengan mudah diselesaikan dengan menambahkan system:/elektra/mountpoints kunci di bawah ini yang config disimpan sebagai field ke struct _Backend .

Pendeknya:

persyaratan minimumnya adalah dimungkinkan untuk meneruskan string apa pun ke keyAddBaseName dan mendapatkan kembali string yang sama ketika meminta nama dasar dengan keyBaseName

Ini mudah. Tetapi menggabungkannya dengan " keyAddBaseName akan menerima semua string" sangat sulit atau hampir tidak mungkin.

Saya melihat sekarang bahwa ini sekali lagi datang menyelesaikan masalah utama di jantung Elektra. Semuanya harus koheren dan sistem yang terdefinisi dengan baik, tetapi pada saat yang sama semuanya harus fleksibel dan plugin harus digunakan sebanyak mungkin. Ini tidak bisa berhasil.

Ya, tapi saya tidak akan menyebutnya masalah tapi tantangan. Kami menginginkan Elektra sebaik mungkin dan tentu saja terkadang terjadi kontradiksi gol.

Seperti yang saya katakan, satu-satunya solusi adalah dengan memperkenalkan sistem yang sangat terbatas, seperti yang @ diusulkan di atas.

Ya, saya juga melihat bahwa tidak mungkin memiliki segalanya. Dengan pelolosan array kita sudah cukup terbatas pada pelolosan awalan, yaitu kita tidak dapat melepaskan karakter lain di dalam nama dasar.

Tapi pelolosan awalan ini mungkin cukup. Dan ini harus diperluas ke semua karakter yang diusulkan di atas. Batasannya adalah bahwa seluruh bagian nama kunci di-escape atau tidak sama sekali.

Tentu saja pelolosan tidak akan terjadi secara ajaib tetapi aplikasi perlu memeriksa apakah arti dari keyBaseName telah diambil atau kami menyediakan keyUnescapedBaseName yang berbeda sehingga pengguna API dapat memiliki string dengan atau tanpa pelolosan awalan.

Mengapa? Semuanya jelas bagi saya, mengapa ini lebih disukai? Nama file UNIX misalnya tidak boleh mengandung / dan tidak ada yang pernah mengira itu masalah. (Tidak mengizinkan / membuat pemisahan jalur UNIX menjadi beberapa bagian jauh lebih sederhana daripada dengan nama kunci).

Ini adalah masalah bagi semua orang yang menerapkan browser file. Beberapa aplikasi memiliki teknik pengkodean URL untuk mendapatkan / ke dalam nama file. "Solusi" yang lebih modern adalah dengan menggunakan Karakter Unicode 'DIVISION SLASH' (U + 2215) untuk garis miring.

Selain itu, perlu diingat bahwa seluruh alasan keberadaan Elektra adalah semantik sistem file UNIX tidak sesuai untuk konfigurasi. Dalam konfigurasi, urutan arbitrer untuk nama bagian kunci termasuk / biasanya digunakan dan karenanya harus didukung. Misal di YAML / diperbolehkan karakter di bagian nama kunci dan juga di TOML ada "Quoted keys".

Kami sudah melanggar (hampir) SETIAP bagian kode yang berinteraksi dengan Elektra dengan menambahkan: setelah namespace. Pada keadaan saat ini, hanya kunci bertingkat tanpa bagian array apa pun dan juga mengecualikan beberapa karakter khusus lainnya yang akan terus berfungsi tanpa memerlukan perubahan. Kompatibilitas mundur sudah lama di luar jendela.

Ya, dan saya sangat bersyukur Anda melakukan ini. Saya tidak akan bisa melakukan ini sendirian.

Saya tidak terlalu yakin tentang itu. Sebenarnya saya tahu hanya satu bagian dari Elektra yang benar-benar mengasumsikan bahwa keyAddBaseName lolos dari segalanya dan itu adalah elektra-kdb dan alat yang membuat mountpoint.

Bagian lainnya adalah SSID. Ini bukan contoh sintetis tetapi Broadcom telah menerapkan ini untuk perangkat bluetooth mereka. Jadi mereka mengandalkan bahwa mereka dapat menambahkan nama dasar apa pun.

Ini mudah. Tetapi menggabungkannya dengan "keyAddBaseName akan menerima semua string" sangat sulit atau hampir tidak mungkin.

Ya, sangat sulit tetapi juga fitur unik yang sangat bagus yang bahkan tidak dimiliki UNIX sebelumnya. Kami bangga akan hal itu.

Misal di YAML / diperbolehkan karakter di bagian nama kunci dan juga di TOML ada "Quoted keys".

Ini sebenarnya yang saya pikir bisa kami perkenalkan, lihat di bawah.

Saya pikir semua ini dapat diselesaikan dengan memperkenalkan sesuatu yang mirip dengan "kunci kutipan". Saya akan memanggil mereka _literal key parts_.

Jika bagian kunci dimulai dengan @ (tentu saja bisa berupa karakter lain), bagian kunci berikut ini adalah _literal key part_. Kunci _literal part_ dapat berisi urutan byte APA PUN termasuk nol byte.

Bentuk unescaped mereka adalah sebagai berikut:

• Kunci _literal bagian_ dimulai dengan karakter @ .
• Selanjutnya @ karakter dikodekan sebagai @@ .
• Nol byte dikodekan sebagai @0 .
• @ mungkin tidak terjadi sebaliknya.
• Seperti biasa, byte nol mengakhiri bagian kunci.

Bentuk pelolosan sedikit berbeda, untuk memudahkan pencetakan:

• Bagian kunci _literal_ dimulai dengan karakter @ .
• Bagian kunci _literal_ TIDAK diakhiri oleh / . Hanya @ diikuti oleh / atau nol byte (akhir string), mengakhiri bagian kunci _literal.
• Setiap byte dapat dikodekan sebagai @XX@ , di mana XX adalah bentuk heksadesimal dari byte. Oleh karena itu @ karakter harus dikodekan sebagai @40@ .

Sekarang keySetBaseName dan keyAddBaseName menerima APAPUN berlaku bagian penting unescaped sebagai argumen. Mereka menyetel / menambahkan argumen mereka tanpa modifikasi sebagai bagian terakhir dari nama kunci yang tidak lolos. Oleh karena itu keyBaseName akan mengembalikan argumen yang sama. Selain itu keySetBaseName dan keyAddBaseName ubah bagian yang tidak lolos ke bentuk pelolosan dan setel / tambahkan sebagai bagian terakhir dari nama yang di-escape.

Untuk mengatasi masalah "kami ingin menambahkan apa pun sebagai bagian penting", kami perkenalkan:

size_t keySetLiteralBaseName (Key * key, char * bytes, size_t size);
size_t keyAddLiteralBaseName (Key * key, char * bytes, size_t size);

Fungsi ini menerima urutan byte APA PUN sebagai argumen bytes . Mereka kemudian mengubah argumen menjadi kunci _literal part_ yang tidak berbentuk dengan mengawali dengan @ , menggantikan @ dengan @@ dan nol byte dengan @0 . Ini kemudian diteruskan ke keySetBaseName atau keyAddBaseName .

Untuk membuat decoding _literal key part_ lebih mudah, kita bisa menambahkan fungsi decoding ke API publik juga.

Saya suka ini jauh lebih baik, karena membuatnya sangat jelas ketika pengguna bermaksud menambahkan hal-hal yang sewenang-wenang ke nama kunci dan saat ini bukan masalahnya.

keySet / AddLiteralBaseName adalah proposal untuk menambahkan fitur baru. Saat ini kami tidak memiliki cara untuk menyandikan byte nol dalam nama kunci. Jika seseorang membutuhkan ini, kami dapat kembali ke proposal Anda.

Untuk saat ini, bagaimanapun, kita membutuhkan semantik yang baik untuk keyAdd / SetBaseName. Seperti yang dijelaskan sangat panjang, idealnya ini harus berupa string apa pun, karena jika tidak, banyak plugin dan aplikasi akan bermasalah karena mereka tidak berharap beberapa string tidak akan berfungsi. #_10 adalah bagian nama kunci yang valid, dapat digunakan sebagai bagian nama kunci pada dasarnya di semua plugin penyimpanan atau aplikasi, kita tidak dapat membahasnya. Ini jelas bukan ide yang baik untuk membiarkan plugin penyimpanan gagal karena menemukan #_10 suatu tempat sebagai bagian nama kunci selama penguraian. Dan juga bukan ide yang baik untuk meminta mereka menggunakan API yang berbeda dengan argumen ukuran jika mereka tidak memiliki byte nol. Sebenarnya kasus seperti #_10 atau / tidak perlu penanganan khusus yang menjadi alasan adanya keyAdd / SetBaseName.

Btw. mungkin lebih baik jika kita bertemu, misalnya pada hari selasa?

Saat ini kami tidak memiliki cara untuk menyandikan byte nol dalam nama kunci. Jika seseorang membutuhkan ini, kami dapat kembali ke proposal Anda.

Ini adalah poin yang paling tidak penting dari proposal. Itu hanya mengizinkan nol byte, karena saya tidak melihat alasan mengapa tidak.

Bagaimanapun, sudah ada kasus penggunaan:

Bagian lainnya adalah SSID. Ini bukan contoh sintetis tetapi Broadcom telah menerapkan ini untuk perangkat bluetooth mereka. Jadi mereka mengandalkan bahwa mereka dapat menambahkan nama dasar apa pun.

Terlepas dari kenyataan bahwa SSID tidak ada hubungannya dengan bluetooth, EEE 802.11 dengan jelas mendefinisikan SSID sebagai urutan byte apa pun yang panjangnya hingga 32 byte. Jadi, baik Broadcom sudah melakukan beberapa pra-pemrosesan untuk menangani nol byte atau kodenya sudah bermasalah. Bagaimanapun, ini jelas merupakan kasus penggunaan untuk mengenkode nol byte dalam nama basis kunci.

Bagaimanapun saya tidak tahu tentang kemungkinan ekstensi masa depan untuk kumpulan karakter khusus, tetapi untuk kumpulan saat ini, saya pikir solusi yang diterapkan di # 3115 mungkin berfungsi sebagaimana adanya.

Jika kami mencoba skenario dari https://github.com/ElektraInitiative/libelektra/issues/2698#issuecomment -554680422 dalam versi ini, hal berikut akan terjadi:

Memanggil keyAddBaseName (key, "#_10") menghasilkan bagian terakhir dari key->key dan dari key->ukey menjadi #_10 . Mengapa? Karena #_10 adalah elemen array yang valid. Ya, jika #_10 adalah SSID, kita tidak akan melihatnya sebagai elemen array, tetapi penggabungan dengan # akan cocok, tetapi apakah itu penting?

Jika kita mengambil elemen array yang tidak valid seperti #10 atau #abc , keyAddBaseName akan keluar dan bagian terakhir nama yang tidak lolos akan menjadi #10 atau #abc , sedangkan bagian terakhir nama yang lolos akan menjadi \#10 atau \#abc .

Saya belum memikirkan tentang aturan teoretis yang kita perlukan agar ini berfungsi untuk ekstensi di masa mendatang, tetapi untuk saat ini saya pikir kita dapat membiarkannya seperti ini. Akan menyenangkan memiliki elemen array tanpa karakter awal, tetapi apakah itu penting? Plugin penyimpanan bebas untuk menyandikan array secara berbeda, jika mereka memiliki masalah dengan karakter # dan untuk baris perintah kita cukup menambahkan kdb array* perintah yang mengambil parameter integer normal, misalnya kdb arrayset /my/array 10 a .

Btw. mungkin lebih baik jika kita bertemu, misalnya pada hari selasa?

Selasa tidak baik bagiku ... Aku akan mengirimimu email.

Terlepas dari fakta bahwa SSID tidak ada hubungannya dengan bluetooth,

Yang saya maksud adalah perangkat Blueray (yang memiliki kemampuan wifi).

EEE 802.11 dengan jelas mendefinisikan SSID sebagai urutan byte apa pun yang panjangnya hingga 32 byte. Jadi, baik Broadcom sudah melakukan beberapa pra-pemrosesan untuk menangani nol byte atau kodenya sudah bermasalah. Bagaimanapun, ini jelas merupakan kasus penggunaan untuk mengenkode nol byte dalam nama basis kunci.

Ya kamu benar. Tetapi ini adalah fitur baru. String apa pun dalam keySetBaseName bukanlah fitur baru.

Karena # _10 adalah elemen array yang valid. Ya, jika # _10 adalah SSID, kita tidak akan melihatnya sebagai elemen array, tetapi penggabungan dengan # akan cocok, tetapi apakah itu penting?

Tidak, itu tidak masalah.

Akan menyenangkan memiliki elemen array tanpa karakter awal, tetapi apakah itu penting?

Tidak, yang paling penting adalah setiap string dapat diumpankan ke keySetBaseName, dan keyBaseName mengembalikan apa yang telah diumpankan sebelumnya. Dengan kebutuhan karakter awal dalam array saya pasti bisa (dan bahagia) hidup.

[...] dan untuk baris perintah kita hanya perlu menambahkan perintah kdb array * yang mengambil parameter integer normal, misalnya kdb arrayset / my / array 10 a.

Kedengarannya seperti rencana yang bagus.

Setelah memeriksa ulang semuanya, saya pikir hanya ada satu konflik. Pernyataan berikut ini tidak dapat disatukan.

1. Bagian kunci yang tidak lolos dapat berisi byte apa pun yang bukan nol.
2. Substring dari bagian kunci yang tidak lolos dapat menentukan properti bagian kunci yang tidak lolos.

Dalam kasus khusus kami. Pernyataan pertama mengikuti dari jaminan untuk keyBaseName et al. dan fakta bahwa Anda tidak ingin keyAddBaseName menolak argumen. Selain itu, proposal "bagian kunci yang tidak berbentuk karakter yang dimulai dengan # selalu indeks array" adalah kasus khusus dari 2.

Ini pada dasarnya berarti untuk menyimpan 1, yang kita inginkan, kita menjadi perlu untuk selalu memeriksa ulang bagian kunci yang tidak lolos, jika Anda ingin menguji properti tertentu. Secara khusus, Anda harus memeriksa bagian kunci unescaped lengkap untuk mengetahui bahwa itu adalah indeks array. Saya menemukan ini situasi yang tidak menguntungkan, tetapi tampaknya tidak dapat dihindari.

Ini juga berarti bahwa kita masih bisa melakukan keseluruhan "bagian kunci yang lolos yang seluruhnya terdiri dari digit adalah indeks array". Efek sampingnya adalah bahwa dalam contoh SSID keyAddBaseName (key, "#_10") akan menghasilkan nama yang lolos yang diakhiri dengan /10 bukan /#_10 . Tapi karena Anda sudah menerima kenyataan bahwa keyAddBaseName (key, "#abc") menghasilkan nama yang lolos yang diakhiri dengan /\#abc , saya berasumsi ini juga tidak menjadi masalah?
Menerapkan ini akan menjadi tugas yang lebih besar, jadi ini akan menjadi PR tindak lanjut # 3115. Saya perlu memeriksa bahwa semua yang bekerja dengan indeks array benar-benar menggunakan nama yang tidak lolos, selain memperbarui semua yang membuat kunci dengan bagian-bagian array.

Sebenarnya 2. tidak selalu dibutuhkan. Kita juga bisa menyimpan string ke-3 yang berisi nama dasar yang akan dikembalikan (mungkin hanya jika diperlukan agar tidak terlalu banyak membuang memori).

Menerapkan ini akan menjadi tugas yang lebih besar

Ini tidak baik, kita juga harus mengakhirinya. Mungkin string ke-3 akan menyelamatkan kita, kita bisa mengoptimalkannya nanti (jika diperlukan).

Apakah kita membuat daftar lengkap persyaratan yang diprioritaskan dalam sebuah keputusan atau kita memenuhi? Keputusan akan berguna pula sehingga orang-orang nantinya akan mengerti mengapa kami melakukannya seperti ini dan persyaratan apa yang kami korbankan untuk persyaratan lainnya.

Sebenarnya 2. tidak selalu dibutuhkan.

Seperti saya katakan, itu adalah proposal. Akan menyenangkan untuk memilikinya, tetapi sayangnya itu tidak berhasil.

Kita juga bisa menyimpan string ke-3 yang berisi nama dasar yang akan dikembalikan (mungkin hanya jika diperlukan agar tidak terlalu banyak membuang memori).

Kita perlu menyimpan versi ketiga dari nama kunci, jika tidak keySetBaseName (key, NULL) akan bekerja dengan baik.

Saat ini tidak banyak properti yang dapat dimiliki bagian penting. Setidaknya bukan properti yang menarik di seluruh Elektra. "Apakah itu bagian indeks array?" sebenarnya satu-satunya yang bisa saya pikirkan. Jika di masa mendatang kita memiliki lebih banyak properti (misalnya jika kita menambahkan konsep "placeholder kontekstual" ke inti), kita dapat memikirkan tentang pengoptimalan.

Ini tidak baik, kita juga harus mengakhirinya.

Saya tahu, itulah mengapa saya mengatakan saya tidak akan melakukannya di # 3115. Jika kami memutuskan kami membutuhkannya, saya akan membuka PR lain. PR kedua ini akan menjadi pekerjaan yang berat dan akan menjadi perubahan besar. Namun, itu harus menjadi perubahan yang jauh lebih kecil dan (sebagian besar) PR simultan lainnya tidak boleh terpengaruh sebanyak yang akan mereka lakukan saat kami menggabungkan # 3115.

Apakah kita membuat daftar lengkap persyaratan yang diprioritaskan dalam sebuah keputusan atau kita memenuhi?

Saya akan menulis dokumentasi, termasuk keputusan, ketika kode # 3115 selesai. Pertanyaan terbukanya saat ini adalah:

1. Selain / dan \ , karakter mana yang dapat memiliki arti khusus di awal bagian kunci?
   Di # 3115 ini sekarang adalah # , % , . dan @ .
2. Apa arti khususnya? Ini bisa berbeda tergantung pada bagian kunci lainnya.
   Di # 3115 kami memiliki yang berikut:
   
   
   
   • # berarti bagian array, jika bagian kunci lainnya hanya digit atau n garis bawah dan kemudian n + 1 digit ( n >= 0 ) dan tidak ada yang lain. Sebagian dari hanya # tidak memiliki arti khusus secara umum (ini dapat berarti globbing array ke beberapa bagian Elektra). Bagian lain yang dimulai dengan # berarti nama kunci tidak valid.
   
   
   • % berarti bagian kosong jika bagian tersebut hanya % . Bagian lain yang dimulai dengan % berarti nama kunci tidak valid.
   
   
   • . memiliki arti khusus hanya jika bagiannya hanya . atau tepat .. . Semua bagian lain yang dimulai dengan . saat ini tidak memiliki arti khusus, yaitu nama kunci tidak valid. (Sebelumnya bagian yang dimulai dengan . membuat kunci tidak aktif)
   
   
   • @ sudah dipesan. Setiap bagian yang dimulai dengan @ berarti nama kunci tidak valid.
   
   
3. Haruskah meng-escape karakter khusus dari 1 selalu diperbolehkan atau hanya jika diperlukan?
   Dalam # 3115, pelarian selalu diperbolehkan.
4. Apakah kita ingin bagian kunci yang seluruhnya terdiri dari digit diinterpretasikan sebagai bagian array? Jika ya, apa representasi kanonisnya? Hanya digit saja, dimulai dengan # lalu hanya digit atau sama dengan versi unescaped, yaitu # dan garis bawah?
   Di # 3115 kita selalu membutuhkan bagian array untuk memulai dengan # dan representasi kanonisnya sama dengan yang tidak di-escape.

Jawaban saya yang disarankan adalah:

1. # , % , . , @ , $ , & dan ? seharusnya cukup untuk kemungkinan penggunaan di masa mendatang. Secara khusus saya pikir kita tidak harus mencadangkan _ yang hanya akan menimbulkan masalah.
2. Seperti yang kita miliki di # 3115. $ , & dan ? dicadangkan untuk penggunaan di masa mendatang seperti @ .
3. Selalu dibolehkan.
4. Secara pribadi, saya menentang itu. Memiliki karakter awal memudahkan untuk menemukan bagian array saat melihat nama kunci. Seperti disarankan di # 2698, setiap benturan dengan karakter khusus dalam format penyimpanan harus diselesaikan dengan plugin penyimpanan bukan inti dan alat kdb seharusnya hanya memiliki perintah array khusus.

Hal yang sedikit tidak berhubungan: Mungkin dimungkinkan untuk mengubah directoryvalue menjadi perpustakaan (atau bahkan menjadikannya bagian dari inti) dan memberikannya antarmuka pribadi yang memungkinkan pembuatan kunci yang tidak mungkin dilakukan melalui API publik. Maka kita tidak perlu khawatir tentang tabrakan karena nama __directoryvalue . Salah satu karakter yang dipesan akan digunakan untuk itu. Saya belum terlalu memikirkannya, tetapi ini mungkin ide yang bagus, karena sebagian besar format penyimpanan baik untuk keterbacaan manusia tidak mendukung kunci dengan nilai dan kunci di bawah ini.

Selain / dan \, karakter mana yang dapat memiliki arti khusus di awal bagian kunci?
Di # 3115 ini saat ini adalah #,%,. dan @.

Pada dasarnya masalah ini adalah: mengumpulkan karakter yang berpotensi memiliki arti khusus (sekarang atau dicadangkan).

Haruskah meng-escape karakter khusus dari 1 selalu diperbolehkan atau hanya jika diperlukan?

Ya, selalu diizinkan.

Apakah kita ingin bagian kunci yang seluruhnya terdiri dari digit diinterpretasikan sebagai bagian array? Jika ya, apa representasi kanonisnya? Hanya angka saja, dimulai dengan # lalu hanya angka atau sama dengan versi unescaped, yaitu # dan garis bawah?

Ini sangat bergantung pada properti dari nama dasar mana yang hilang. Dari perspektif pengguna, "bagus" jika tidak diperlukan # , dari sudut pandang API, sangat penting bahwa keySet/AddBaseName berfungsi.

Secara khusus saya pikir kita tidak harus memesan _ yang hanya akan menimbulkan masalah.

Dan untuk mengubah globbing menjadi * ?

Memiliki karakter awal memudahkan untuk menemukan bagian array saat melihat nama kunci.

Menurut saya ini bukan masalah besar: angka dalam string juga cukup mudah dikenali:

user/here/is/a/test/1/not/a/number/4/here/is/a/number

Maka kita tidak perlu khawatir tentang tabrakan karena nama __directoryvalue.

Jika diimplementasikan dengan benar kita tidak perlu khawatir juga jika diimplementasikan sebagai plugin, plugin bisa lolos dari __directoryvalue yang sudah ada.

Impian saya adalah keySetBaseName akan keluar dari _directoryvalue (satu garis bawah atau @ sudah cukup), tetapi plugin directoryvalue akan menggunakan keyAddName untuk mendapatkan _directoryvalue mentah di dalam nama kunci. (Yang akan dilindungi karena garis bawah atau @ adalah karakter khusus yang tidak digunakan untuk aplikasi).

Semoga bisa kita bahas hari ini, semoga dengan cara ini kita bisa lebih mudah mengambil kesimpulan.

Ini sangat bergantung pada properti dari nama dasar mana yang hilang.

Seperti yang saya katakan, kita seharusnya tidak kehilangan apa pun dibandingkan dengan kondisi # 3115 saat ini, tetapi kita juga belum tentu mendapatkan banyak keuntungan. Pertanyaan utamanya adalah berapa banyak pekerjaan yang ingin kita investasikan untuk perubahan nama kunci. Mari kita bicarakan hari ini.

Dan untuk mengubah globbing menjadi * ?

* sudah memiliki arti bagi pustaka globbing. Itu berarti setiap bagian penting. # hanya cocok dengan bagian array dan _ cocok dengan bagian non-array.

Menurut saya ini bukan masalah besar: angka dalam string juga cukup mudah dikenali

Ini mungkin hanya saya, tetapi saya tidak melihat /1/ pada awalnya.

Jika diimplementasikan dengan benar kita tidak perlu khawatir juga jika diimplementasikan sebagai plugin, plugin bisa lolos dari __directoryvalue yang sudah ada.

Lihat # 3256 untuk solusi alternatif menggunakan metakeys.

Impian saya adalah keySetBaseName akan keluar dari _directoryvalue

Saya sangat menentang itu. Inti harus tidak peduli dengan cara apapun dengan apa yang plugin lakukan, atau apa persyaratan yang mereka miliki. Ini juga menjadi preseden buruk. Bagaimana jika plugin lain menggunakan _averyspecialkey untuk sesuatu? Apakah kita akan memperbarui keySetBaseName setiap kali ini terjadi?

Hasil pembicaraan:

• properti nama dasar tampaknya lebih atau kurang seperti sebelumnya
• array akan terus dimulai dengan # (tetapi _ tidak akan diperlukan)
• karakter di atas akan di-escape jika berada di posisi pertama, kecuali: #
• keySetBaseName tidak akan dan tidak dapat diperbarui untuk karakter baru, daftar di atas (setelah diselesaikan) adalah daftar lengkap untuk Elektra 1.0

karakter di atas akan di-escape jika berada di posisi pertama, kecuali: #

Perilaku saat ini (di # 3115) dari keySetBaseName dan keyAddBaseName ditentukan oleh fungsi ini:

https://github.com/ElektraInitiative/libelektra/blob/9e91654ca72e6cd58b3b54892e78b5a5b2810214/src/libs/elektra/keyname.c#L1360 -L1462

Kami hanya melarikan diri jika diperlukan untuk menghindari pelolosan yang tidak perlu dalam nama yang lolos.

Juga karena Anda bertanya, apakah ada hubungan 1: 1 antara nama kunci yang di-escape dan yang tidak di-escape:

Tidak, tidak ada. Kami memutuskan untuk mengizinkan pelarian yang tidak perlu:

Haruskah meng-escape karakter khusus dari 1 selalu diperbolehkan atau hanya jika diperlukan?

Ya, selalu diizinkan.

Ini berarti bahwa misalnya /key/%abc dan /key/\%abc adalah nama kunci yang di-escape yang berbeda untuk nama kunci yang tidak di-escape yang sama. Yaitu satu dengan namespace bertingkat dan dua bagian key dan %abc .

Jika kami ingin memastikan relasi 1: 1, kami dapat mengatakan bahwa pelolosan hanya diizinkan jika diperlukan (tidak seperti itu), atau menghapus garis miring terbalik yang tidak perlu selama langkah kanonikalisasi.
Dalam kasus apapun relasi 1: 1 mensyaratkan bahwa keySetBaseName dan keyAddBaseName berperilaku seperti dijelaskan di atas, yaitu ia harus tahu kapan untuk melarikan diri diperlukan.

Secara pribadi, saya rasa relasi 1: 1 tidak diperlukan. Kita hanya membutuhkan relasi: 1 untuk membuat ksLookup berfungsi. Biasanya seharusnya tidak menjadi masalah, jika kita mencari /key/\%abc dan mendapatkan kembali /key/%abc atau sebaliknya.

Terima kasih telah menyelidiki perilaku pulang-pergi. Ya, pencariannya bukan masalah besar (ini sudah 1: n karena berjenjang) tetapi kunci dengan nama yang berbeda menghapus dirinya sendiri saat menambahkannya ke kumpulan kunci itu jelek. Dan tentu saja bahwa itu tidak round-trip adalah tujuan penting lainnya: Setiap KeySet setelah serialisasi dan serialisasi harus persis sama, dan ini tidak akan diberikan jika \% dan % adalah "identik "dalam representasi internal.

Apakah Anda mungkin memiliki solusi untuk masalah ksAppend dan round-tripping?

Ini masalah definisi. Apa yang secara unik mengidentifikasi kunci?

Jawaban teknisnya adalah nama yang tidak lolos. Inilah yang digunakan KeySet untuk membedakan antar kunci.
Pengguna hanya perlu membiasakan diri mengetahui bila dua nama kunci itu sama. Ini mirip dengan melihat bahwa pecahan 2/3 dan 4/6 adalah sama.

Jika Anda masih menginginkan relasi 1: 1, pelolosan hanya diperbolehkan jika diperlukan. Itu bukan upaya lebih untuk diterapkan, tetapi mungkin mengganggu pengguna.

Ini masalah definisi. Apa yang secara unik mengidentifikasi kunci?

Sampai saat ini, mengatakan "nama mengidentifikasi kunci" sudah cukup karena ada 1: 1 antara lolos dan tidak lolos. Mereka hanya disimpan berdua sebagai peningkatan kinerja. (ruang vs. waktu)

Saya lebih suka jika bisa tetap seperti ini.

Jika Anda masih menginginkan relasi 1: 1, pelolosan hanya diperbolehkan jika diperlukan. Itu bukan upaya lebih untuk diterapkan, tetapi mungkin mengganggu pengguna.

Mengapa itu mengganggu?

Ide saya tentang \#123 vs. #123 adalah bahwa itu bukan nama kunci yang sama dan tidak memiliki arti yang sama (satu berarti literal #123 , yang lainnya adalah yang ke-124 entri array). Mereka berdua akan memiliki nama escape dan unescaped yang berbeda.

Jika mereka sekarang memiliki nama unescaped yang sama, kita dapat dengan mudah menolak keyAddName(k, "\\#123") . Tidak ada manfaatnya memilikinya, atau ada?

Ide saya tentang \#123 vs. #123 adalah bahwa itu bukan nama kunci yang sama dan tidak memiliki arti yang sama (satu berarti literal #123 , yang lainnya adalah yang ke-124 entri array). Mereka berdua akan memiliki nama escape dan unescaped yang berbeda.

Contoh itu tidak menunjukkan apa-apa. Jelas \#123 dan #123 memiliki versi unescaped yang berbeda, jika tidak maka tidak mungkin mendapatkan bagian yang tidak lolos #123 dengan cara apapun.

Array juga merupakan contoh yang buruk, karena kita mengatakan # harus memasukkan bagian array yang valid atau di-escape, untuk menghindari kesalahan yang mudah. Sebaliknya mari kita lihat % .

Jika bagian yang lolos adalah /%/ , kita mendapatkan bagian kosong yang tidak di-escape dan jika /\%/ kita mendapatkan bagian yang tidak di-escape % . Jelas keduanya harus merupakan bagian kunci lolos yang valid. Sejauh ini bagus.
Pertanyaannya sekarang adalah tentang bagian /%abc/ dan /\%abc/ . Keduanya memetakan ke bagian yang tidak lolos %abc . Apakah keduanya diperbolehkan, atau salah satunya tidak valid? Jika keduanya diizinkan, kami tidak memiliki relasi 1: 1.

Inilah yang saya maksud dengan:

Haruskah meng-escape karakter khusus dari 1 selalu diperbolehkan atau hanya jika diperlukan?

Yang Anda balas:

Ya, selalu diizinkan.

Yang saya tafsirkan sebagai /%abc/ dan /\%abc/ diperbolehkan. Saya menyadari sekarang bahwa Anda mungkin bermaksud "Ya, selalu diperlukan", yaitu hanya /\%abc/ yang valid.

Ngomong-ngomong ...
Kami memiliki dua opsi di sini:

1. Karakter yang dicadangkan harus memasukkan bagian yang valid dengan arti khusus, atau harus di-escape.
   Dalam contoh di atas, ini berarti hanya /\%abc/ yang valid.
2. Karakter yang dicadangkan hanya boleh di-escape, jika bagian tersebut memiliki arti khusus tanpa escape.
   Dalam contoh di atas, ini berarti hanya /%abc/ yang valid.

Pilihan dapat dibuat secara independen untuk masing-masing karakter yang dipesan. Hanya satu dari opsi ini yang dapat dipilih per karakter untuk mempertahankan relasi 1: 1.

Di # 3115 saat ini opsi 1 untuk # dan opsi 2 untuk . dan % . Untuk @ kedua opsinya sama, selalu membutuhkan pelolosan. Tidak ada bagian valid yang dimulai dengan @ . Saya harus memeriksa semuanya sudah benar, tapi saya pikir kita memiliki hubungan 1: 1 di # 3115 sekarang.

Terima kasih atas penjelasan detailnya. Ya, tidak terlalu penting bahwa /%abc/ dapat di-escape dengan satu garis miring ke belakang. Pulang pergi jauh lebih penting. Kita juga dapat menggunakan sesuatu yang lain untuk menghindarinya (pada lapisan di atas.)

Tidak ada bagian valid yang dimulai dengan @.

Bagaimana cara kerjanya ketika kita menetapkan @ a makna?

Saya harus memeriksa semuanya sudah benar, tapi saya pikir kita memiliki hubungan 1: 1 di # 3115 sekarang.

Terima kasih: 100:

Bagaimana cara kerjanya jika kita memberikan @ arti?

Anda benar, untuk memastikan kompatibilitas di masa mendatang, kami harus memilih opsi 1. Mudah untuk melihat:
/\%abc/ , /%/ dan /\%/ tidak valid, tetapi /%abc/ tidak valid. Semua bagian yang dimulai dengan @ tidak valid sekarang, tetapi memulai dengan \@ diperbolehkan dan akan tetap benar, jika beberapa bagian yang dimulai dengan @ menjadi valid.

Saya menghapus set aturan yang saya posting sebelumnya, karena setelah bermain dengan tata bahasa ANTLR saya perhatikan bahwa aturan tersebut tidak membantu. Saya pikir memiliki hubungan 1: 1 DAN memastikan kompatibilitas ke belakang saat memberikan makna karakter yang dicadangkan pada dasarnya tidak mungkin.

Mari kita ambil @ sebagai contoh. Saat ini hanya bagian yang dimulai dengan \@ yang valid, bagian yang dimulai dengan @ selalu tidak valid. Bagian dari formulir \@XYZ ( XYZ sewenang-wenang) tidak diubah menjadi @XYZ .

Sekarang kami memutuskan untuk memperkenalkan makna untuk @ . Semua bagian dari formulir @XYZ ( XYZ sewenang-wenang) yang predikat foo(XYZ) ( foo adalah beberapa predikat string) benar sekarang tidak lolos ke bar(XYZ) ( bar adalah beberapa fungsi yang memetakan string ke string). Untuk mempertahankan relasi 1: 1, kita harus memastikan bahwa tidak ada bagian lain yang tidak lolos ke bar(XYZ) . Tetapi itu berarti beberapa kunci yang saat ini valid akan menjadi tidak valid, karena saat ini dimungkinkan untuk mendapatkan kunci dengan nama yang tidak dapat di-escape. Ini merusak kompatibilitas. (Catatan: Mungkin saja menjaga relasi 1: 1 dan perilaku bolak-balik yang longgar antara versi "tidak ada artinya untuk @ " dan "artinya untuk @ ", tapi itu hanya berbeda melanggar perubahan.)

Saya mungkin punya solusi untuk ini, tetapi saya sudah tahu Anda tidak akan menyukainya, karena ini melibatkan pelarangan nama tertentu yang tidak bisa dihilangkan.

Penjelasan solusi saya menjadi cukup panjang, jadi saya memasukkan ke dalam file di # 3115.

Ide dasarnya adalah:

• Tidak semua urutan byte adalah nama kunci yang tidak lolos lagi. Beberapa C-string tidak lagi valid sebagai bagian nama kunci yang tidak lolos.
• Hal ini membuat hubungan bukti 1: 1 di masa mendatang dari nama kunci yang lolos dan tidak lolos menjadi mungkin. String dapat menjadi bagian kunci yang tidak lolos yang valid, tetapi setelah string valid, string tidak dapat menjadi tidak valid lagi.

Penjelasan rinci dan artinya dapat ditemukan di sini . Anda dapat menambahkan komentar di sini: https://github.com/ElektraInitiative/libelektra/commit/86d8e7806bfb92e95a7c519e09e95fa278eadb05

Terima kasih banyak telah mengerjakan ini! @sanssecours, bisakah Anda melihatnya jika Anda juga menyukai idenya?

Saya mungkin punya solusi untuk ini, tetapi saya sudah tahu Anda tidak akan menyukainya, karena ini melibatkan pelarangan nama tertentu yang tidak bisa dihilangkan.

Btw. bukan karena "Saya tidak suka", tetapi tidak ada yang akan menyukai Elektra jika semua plugin penyimpanan bermasalah karena tidak dapat menerima beberapa string.

buggy karena mereka tidak dapat menerima beberapa string

Itu bukan buggy, jika kita mendefinisikannya seperti itu. JSON membutuhkan pelolosan yang mirip dengan string C. Tidak ada yang mengeluh tentang itu. Setiap plugin Elektra yang menggunakan JSON hanya perlu menggunakan beberapa escapes lagi.

Meskipun harus terlihat dari definisi yang lebih rinci, saya mungkin seharusnya secara eksplisit menyatakan bahwa tidak ada fungsi aktual yang hilang. Ini hanya sedikit lebih rumit dalam beberapa kasus.

Untuk setiap urutan byte masih ada satu nama kunci yang tidak lolos yang mewakili urutan byte ini. Hanya saja urutan byte asli dan nama kunci yang tidak lolos yang mewakilinya tidak akan selalu sama lagi.

Itu bukan buggy, jika kita mendefinisikannya seperti itu. JSON membutuhkan pelolosan yang mirip dengan string C. Tidak ada yang mengeluh tentang itu. Setiap plugin Elektra yang menggunakan JSON hanya perlu menggunakan beberapa escapes lagi.

Anda membandingkan apel dengan pisang di sini. JSON adalah format serialisasi, kami membahas struktur data di sini (KeySet). Pada tingkat serialisasi, plugin penyimpanan masih perlu meng-escape / unescape nama kunci dan nilai kunci agar pemisah dapat dibedakan.

Meskipun harus terlihat dari definisi yang lebih rinci, saya mungkin seharusnya secara eksplisit menyatakan bahwa tidak ada fungsi aktual yang hilang. Ini hanya sedikit lebih rumit dalam beberapa kasus.

Tanpa API sulit untuk mengatakan apa artinya "sedikit lebih rumit".

Hanya saja urutan byte asli dan nama kunci yang tidak lolos yang mewakilinya tidak akan selalu sama lagi.

Saya pikir kita bisa hidup dengan itu.

Saya hanya khawatir perubahan ini akan terlalu besar (sepertinya juga diperlukan modifikasi pada semua plugin penyimpanan) dan kami tidak akan dapat menyelesaikannya. Mungkin lebih baik melupakan pemilahan alami yang menyebabkan sebagian besar masalah ini?

Mungkin lebih baik melupakan pemilahan alami yang menyebabkan sebagian besar masalah ini?

Pemilahan alami tidak ada hubungannya dengan ini. AFAIK, bahkan tidak disebutkan di mana pun dalam proposal. Masalahnya adalah tentang membalikkan karakter untuk penggunaan di masa mendatang sambil menghindari perubahan yang merusak.

Tanpa API sulit untuk mengatakan apa artinya "sedikit lebih rumit".

API ada dalam proposal. Dalam hal ini "sedikit lebih rumit" berarti memilih di antara dua operasi ( pushL dan pushU , nama adalah placeholder) daripada selalu menggunakan yang sama ( keyAddBaseName ). Dan terkadang mengabaikan garis miring terbalik saat membandingkan bagian kunci dengan string.

Saya hanya khawatir perubahan ini akan terlalu besar

Tentu saja ini adalah perubahan besar, tetapi itu akan mengurangi perubahan yang merusak di masa depan.

kami tidak akan bisa menyelesaikannya

Itu sepenuhnya tergantung pada tenggat waktu ...

Seperti yang telah dibahas, saya pikir kita sebaiknya melupakan masalah ini (reservasi karakter khusus). Sebaliknya pelolosan tingkat yang lebih tinggi (seperti array # , % ) atau reservasi karakter khusus ( @ ) harus langsung dilakukan di plugin penyimpanan.

Itu sepenuhnya tergantung pada tenggat waktu ...

Jika Anda ingin membuat tesis master tentang perpustakaan perangkat lunak yang tahan masa depan, Anda bebas membuka kembali topik ini: wink:

Seperti yang dibahas [...]

Bukan itu yang saya ingat dari diskusi itu. Saya pikir kita setuju untuk menyelesaikan # 3115 dan kemudian memikirkan masalah ini lagi.

Saya akan menyelesaikan # 3115 dan saya juga akan menambahkan beberapa contoh dan penjelasan bahasa Inggris sederhana ke proposal.

Sebaliknya pelolosan tingkat yang lebih tinggi (seperti array #,%) atau reservasi karakter khusus (@) harus dilakukan secara langsung di plugin penyimpanan.

Sejujurnya ini adalah solusi yang bodoh ...

Setiap kali kami menambahkan sesuatu yang baru ke nama kunci, kami harus memperbarui semua plugin penyimpanan. Itulah alasan Anda menggunakan solusi saya (yang hanya membutuhkan ini sekali).

Itu juga tidak menghindari pembaruan plugin sekarang, karena AFAIK tidak satupun dari mereka benar-benar menangani nama kunci 100% benar (bagian array).

Jika Anda benar-benar tidak menginginkan proposal saya, berikan alasan untuk menentangnya, alih-alih mengusulkan solusi yang tidak menyelesaikan apa pun dan hampir sama banyaknya dengan upaya.

Jika Anda ingin membuat tesis master tentang perpustakaan perangkat lunak yang tahan masa depan

Tidak, saya tidak ingin melakukan itu ... Saya hanya ingin membuat nama kunci Electra menjadi bukti masa depan, yang merupakan tugas yang jauh lebih kecil dan sederhana.

Bukan itu yang saya ingat dari diskusi itu. Saya pikir kita setuju untuk menyelesaikan # 3115 dan kemudian memikirkan masalah ini lagi.

Ya, kami tidak menyelesaikan diskusi tetapi:

• rekomendasi saya adalah memperbaiki bug penting lainnya dan masalah kegunaan.
• Saya tidak bisa dan tidak akan melarang Anda untuk memikirkannya: wink:

Itu juga tidak menghindari pembaruan plugin sekarang, karena AFAIK tidak satupun dari mereka benar-benar menangani nama kunci 100% benar (bagian array).

Silakan laporkan bug. Menggunakan array seperti yang ditentukan dalam doc / decision / array.md seharusnya sudah benar. Kemudian #0 adalah "nama sederhana tanpa arti" dan array hanya mendapatkan arti dengan kunci tepat di bawahnya yang memiliki "array" metadata.

Jika Anda benar-benar tidak menginginkan proposal saya, tolong beri alasan untuk menentangnya,

Saya sangat menyukai lamaran itu. Tetapi hal-hal seperti # 1074 (dan lihat https://github.com/ElektraInitiative/libelektra/projects/9 untuk informasi lebih lanjut) IMHO jauh lebih penting untuk kesuksesan Elektra.

alih-alih mengusulkan solusi yang tidak menyelesaikan apa pun dan hampir sama banyaknya dengan upaya.

Maksud kamu apa? Proposal terakhir saya adalah tidak mencadangkan karakter dan menyerahkannya pada plugin penyimpanan untuk melakukan apa yang mereka inginkan. Saya tidak melihat adanya upaya dalam "menerapkan" proposal ini (ini adalah NOP).

Tidak, saya tidak ingin melakukan itu ... Saya hanya ingin membuat nama kunci Electra menjadi bukti masa depan, yang merupakan tugas yang jauh lebih kecil dan sederhana.

Mungkin ini sudah cukup untuk skripsi kalau buktinya sudah selesai. Saya tidak melihat pekerjaan terkait, mungkin orang lain sudah melakukan hal seperti ini.

Menggunakan array seperti yang ditentukan dalam doc / decision / array.md seharusnya sudah benar.

Itu mungkin masalahnya, tetapi tutorial untuk plugin penyimpanan tidak setuju dan bahkan menunjukkan bahwa yamlcpp tidak berfungsi dengan cara ini.

Tetapi hal-hal seperti # 1074 adalah IMHO jauh lebih penting untuk kesuksesan Elektra.

Saya prihatin dengan perubahan nama kunci, karena itulah yang sudah saya lakukan dan saya memiliki banyak wawasan saat ini. Selain itu, kami sudah memiliki perubahan yang dapat merusak nama-nama kunci, jadi tidak terlalu menjadi masalah, jika kami merusak lebih banyak hal.

Mountpoint pengguna / dir akan menyenangkan ya, tapi saya tidak tahu bagaimana menyelesaikannya. Mungkin perlu waktu lama atau lebih lama bagi saya untuk menemukan dan menerapkan solusi, karena saya perlu menerapkan perubahan yang saya usulkan pada nama kunci.

Usulan terakhir saya adalah tidak memesan karakter

Anda menyebutkan memesan @ .

serahkan pada plugin penyimpanan untuk melakukan apa yang mereka inginkan

Itu hanya mengarah pada ketidakcocokan. Tentu saja kami tidak dapat menghentikan plugin penyimpanan menggunakan format yang sama sekali berbeda, tetapi tidak memberikan pedoman apa pun hanya sekadar menanyakan masalah.

Itu mungkin masalahnya, tetapi tutorial untuk plugin penyimpanan tidak setuju dan bahkan menunjukkan bahwa yamlcpp tidak berfungsi dengan cara ini.

@sanssecours dapatkah Anda melihat ini? Jika kita mengenali array hanya karena strukturnya (nama dengan #0 ) KeySet tidak akan berbentuk bulat.

Mungkin perlu waktu lama atau lebih lama bagi saya untuk menemukan dan menerapkan solusi

Ya, tetapi mountpoint user / dir adalah sesuatu yang sering dihadapi oleh setiap pengguna Elektra. Jika kita membutuhkan karakter cadangan tidak diketahui.

Anda menyebutkan memesan @.

Ya, plugin penyimpanan dapat memesan dan menghindari apa pun yang mereka inginkan.

Itu hanya mengarah pada ketidakcocokan. Tentu saja kami tidak dapat menghentikan plugin penyimpanan menggunakan format yang sama sekali berbeda, tetapi tidak memberikan pedoman apa pun hanya sekadar menanyakan masalah.

Saya sangat setuju. Mungkin beberapa orang dalam beberapa tahun akan membenci kita karena tidak menyimpan beberapa karakter (tapi mungkin juga tidak). Tapi saya yakin itu tidak akan berkontribusi pada kesuksesan Elektra 1.0. Untuk memperjelas: Saya sama sekali tidak menentang penerapannya tetapi hal-hal lain (https://github.com/ElektraInitiative/libelektra/projects/9) adalah IMHO jauh lebih tinggi dalam daftar prioritas. Anda bebas untuk tidak setuju dan tetap menerapkannya. Saya tidak akan menolak PR selama tidak terlalu rumit untuk plugin penyimpanan (dan semua plugin diperbaiki). Tapi ada risiko tinggi bahwa hal-hal lain (yang penting untuk keberhasilan) tidak mendapatkan diimplementasikan dan Elektra tidak akan digunakan dalam proyek-proyek penting seperti KDE.

@sanssecours dapatkah Anda melihat ini? Jika kita mengenali array hanya karena strukturnya (nama dengan #0 ) KeySet tidak akan berbentuk bulat.

Saya memperbarui perilaku YAML CPP dan plugin Nilai Direktori di PR 3357. Permintaan pull juga memperbarui bagian dari dokumentasi untuk memperhitungkan metadata wajib array .

Saya sekarang telah memperbarui proposal di # 3447. Saya harap sekarang lebih mudah untuk dipahami (masih sangat panjang).

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

@ markus2330 Saya akan taruh ini di sini meskipun diskusi sebelumnya ada di # 3223, karena saya pikir itu lebih cocok.

Saya baru saja menemukan / ingat bahwa dalam versi Elektra [1] saat ini, sudah terjadi (dan diterapkan seperti itu) bahwa "setiap bagian Nama Kunci ESCAPED yang dimulai dengan @ membuat seluruh Kunci tidak valid". Ini berarti kami dapat - tanpa menerapkan perubahan lain apa pun dari proposal - menggunakan nama bidang yang dimulai dengan @ untuk tujuan khusus dalam plugin penyimpanan, seperti yang disarankan proposal dengan $meta dan $value .

@ bauhaus93 Ini mungkin membantu Anda ketika Anda mengimplementasikan dan metadata di toml (dan juga untuk kunci nilai non-daun, sampai batas tertentu).

Bagi mereka yang belum membaca proposal, idenya pada dasarnya adalah (untuk JSON):

{
   "key": {
        "@value": "127.0.0.1",
        "sub": "xyz",
        "@meta": {
            "check/ipaddr": "ipv4"
      }
}

Berubah menjadi dua kunci:

key = 127.0.0.1
key/sub = xyz

dan key juga memiliki metadata ini:

check/ipaddr = ipv4

~ Karena key/@value dan key/@meta adalah nama kunci yang dicadangkan (atau bahkan tidak valid di # 3447), ini tidak dapat menyebabkan konflik apa pun. ~

[1] master hanya menyebutkan ini dalam dokumentasi , tetapi memungkinkan Anda membuat Kunci tersebut. # 3447 di sisi lain ~ melarang semua kunci ini sepenuhnya ~ mensyaratkan bahwa @ -escape pada awal bagian nama kunci dalam nama kunci yang di-escape. Dokumentasi juga memiliki ketentuan serupa untuk _ , tetapi itu juga tidak diterapkan di # 3447.

Maaf atas kebingungannya, tetapi saya harus mengklarifikasi bagian dari komentar di atas. Bagian tentang @ hanya berlaku untuk Nama Kunci yang lolos. Nama unescaped (sebagai C-String) "\01\00key\00@meta\00" masih berlaku di # 3447, seperti sebelumnya. Ini berarti @meta tidak dapat digunakan untuk metadata tanpa pertimbangan lebih lanjut dalam plugin penyimpanan.

Namun, karena itu selalu merupakan nama yang dicadangkan dan kami akan memerlukan pelolosan di # 3447, saya pikir masih adil untuk menggunakannya dalam plugin penyimpanan. Pengguna IMO tidak boleh berharap bahwa nama yang dicadangkan selalu dapat digunakan tanpa masalah. Tapi tentu saja kita perlu berhati-hati. Salah satu kemungkinannya adalah ini (JSON lagi):

{
   "key": {
        "@value": "127.0.0.1",
        "@sub": "xyz",
        "@meta": {
            "check/ipaddr": "ipv4"
      }
}

Berubah menjadi dua kunci (perhatikan \ untuk melarikan diri):

key = 127.0.0.1
key/\<strong i="15">@sub</strong> = xyz

Tapi ini

{
   "key": {
        "@@value": "127.0.0.1",
        "@@sub": "xyz",
        "@@@sub": "abc",
        "@@meta": {
            "check/ipaddr": "ipv4"
      }
}

Ternyata menjadi (lagi \ untuk melarikan diri):

key/\<strong i="23">@value</strong> = 127.0.0.1
key/\<strong i="24">@sub</strong> = xyz
key/\@<strong i="25">@sub</strong> = abc
key/\@meta/check\/ipaddr = ipv4

Aturannya di sini adalah:

• nama field tidak dimulai dengan @ -> gunakan nama field dan tambahkan dengan keyAddBaseName
• nama bidang dimulai dengan lebih dari satu @ -> hapus @ dan gunakan sisanya untuk keyAddBaseName
• nama bidang dimulai dengan satu @ -> periksa apakah nama bidang memiliki arti khusus (misalnya @value atau @meta ):
  
  
  
  • jika memiliki arti khusus, proseslah sesuai
  
  
  • jika tidak, gunakan saja nama field untuk keyAddBaseName (misal @sub )
  
  

(Catatan: keyAddBaseName mengambil nama yang tidak lolos dan melakukan pelolosan yang diperlukan untuk menjaga nama kunci tetap valid)

Saya tidak mengerti tujuan dari dua komentar terakhir, apakah ini proposal tentang penggantian plugin directoryvalue?

(perhatikan \ untuk melarikan diri)

Untuk @ kami biasanya menggunakan @ untuk meloloskan diri, jadi cukup buang @ jika ada beberapa. Akan lebih baik jika ini juga didokumentasikan dalam deskripsi nama kunci. Kita bisa mengubah ke \ (jika itu membuat pelolosan untuk nama kunci secara umum lebih mudah dimengerti) tetapi ini membutuhkan perubahan setidaknya di plugin base64. (plugin null dihapus di # 3491)

Saya tidak mengerti tujuan dari dua komentar terakhir, apakah ini proposal tentang penggantian plugin directoryvalue?

Bagian @value adalah ya. Tapi itu lebih umum. @meta dapat digunakan untuk menyimpan metadata di dalam format dengan struktur objek bersarang tunggal, seperti JSON atau TOML (masih tidak yakin tentang YAML, karena tag).
Pada dasarnya, karena semua yang ada di file JSON mengacu pada beberapa kunci di suatu tempat, tidak ada tempat untuk menyimpan metadata. Kecuali memaksakan beberapa batasan pada struktur file JSON, tetapi Anda mungkin tidak bisa memasang beberapa file konfigurasi begitu saja. [1]

Seperti yang saya katakan, Anda perlu menerapkan batasan untuk menyesuaikan metadata ke dalam JSON (AFAIK, hal yang sama berlaku untuk TOML). Jadi ya, proposal saya di komentar di atas memang memberlakukan pembatasan pada file JSON, tetapi aplikasi yang menggunakan @ pada awal kolom JSON mungkin cukup jarang.

Untuk @ kami biasanya menggunakan @ untuk meloloskan diri, jadi cukup buang @ pertama jika ada beberapa. Akan lebih baik jika ini juga didokumentasikan dalam deskripsi nama kunci. Kita bisa mengubah ke \ (jika itu membuat pelolosan untuk nama kunci secara umum lebih mudah dimengerti) tetapi ini membutuhkan perubahan setidaknya di plugin base64.

Tidak yakin bagaimana plugin base64 relevan di sini, tapi seperti yang saya perjelas:

Pada master (6a1535c094c7be2f441bd0e7b0dda1c50e97ee1d saat ini) keyNew ("/elektra/@abc", KEY_END) berfungsi dan membuat nama yang tidak dapat lolos dengan bagian elektra dan @abc .
Di # 3447 keyNew ("/elektra/@abc", KEY_END) mengembalikan NULL karena nama dianggap tidak valid, tetapi keyNew ("/elektra/\@abc", KEY_END) berfungsi dan membuat nama yang tidak lolos dengan bagian elektra dan @abc .
Tidak yakin apa yang dilakukan keyNew ("/elektra/\@abc", KEY_END) pada master.

keyAddBaseName (k, "@abc") berfungsi dalam kedua kasus tersebut, satu-satunya perbedaan adalah nama yang di-escape yang dibuatnya.

Saya juga tidak ingat, mengapa saya melakukan perubahan ini. Mungkin ada alasan bagus, tetapi bagaimanapun itu dilakukan sekarang dan saya tidak berpikir mengubahnya kembali akan mudah.

[1] Seperti biasa, masalahnya di sini adalah Elektra ingin melakukan segalanya dan menyenangkan semua orang. Di satu sisi kami ingin mengizinkan plugin penyimpanan yang dapat membaca file sembarang dalam format standar (mis. JSON) dan mengubahnya menjadi KeySets. Di sisi lain, kami ingin mengizinkan aplikasi menggunakan string arbitrer sebagai bagian dari nama kunci. Ini mungkin berhasil untuk beberapa waktu, tetapi setidaknya ketika Anda mendapatkan metadata, itu rusak untuk format tertentu.

JSON adalah pohon tunggal dengan nilai hanya di simpul daun. KeySets adalah pohon dengan nilai di setiap node, dan beberapa node juga memiliki link ke seluruh pohon yang terpisah. Anda mungkin dapat mengonversi di antara keduanya, tetapi salah satu dari mereka harus memberlakukan batasan pada yang lain untuk memiliki konversi tanpa kerugian.

Seperti yang saya katakan, Anda perlu menerapkan batasan untuk menyesuaikan metadata

@ kodebach apakah ini berarti Anda mendukung pembatasan format metadata yang dapat disimpan?

Saya tidak pernah menemukan ini, karena saya kebanyakan menggunakan dump dan kemudian mmapstorage dan jarang konfigurasi yang diimpor / diekspor menggunakan plugin lain. Ini sangat disayangkan. Sebagai pengguna saya lebih suka dapat mengimpor / mengekspor ke spesifikasi standar (kehilangan metadata) sambil menyimpan data nyata (termasuk metadata) menggunakan format internal elektra sewenang-wenang.

Saya pikir membatasi format bisa membingungkan pengguna. Misalnya, jika Elektra menyediakan plugin JSON non-eksperimental, maka saya berharap dapat menangani input yang sesuai dengan spesifikasi. Tidak jelas bagi saya bagaimana pengguna dapat memeriksa bahwa file konfigurasinya sesuai dengan spesifikasi yang dibatasi.

@ markus2330 apa pendapat Anda tentang penerapan pembatasan pada format?

EDIT: Saya setuju bahwa "Elektra ingin melakukan segalanya dan menyenangkan semua orang" adalah masalah.

apakah ini berarti Anda mendukung pembatasan format metadata yang dapat disimpan?

Kita perlu menentukan prioritas kita. Apa sebenarnya yang mutlak harus, dan di mana hal-hal bisa berubah. Seperti sekarang ini, satu-satunya cara untuk banyak format adalah dengan menyimpan metadata dalam komentar ( @ bauhaus93 melakukannya di # 3500 untuk TOML). IMO ini bukan solusi, tetapi hanya solusi kikuk. Bagian terburuknya adalah penyalahgunaan bagian yang tidak boleh disentuh oleh parser dan secara drastis dapat mempengaruhi keterbacaan file penyimpanan. Beberapa format (yaitu JSON) juga tidak memiliki komentar.

Pembatasan yang sangat mendasar yang dapat kami terapkan (menggunakan JSON sebagai contoh lagi) adalah semua file harus terlihat seperti ini:

{
    "kdb": {
       "elektra": {
          "version": 1
        }
    },
    "meta": {
       "elektra/version": {
           "type": "long"
       }
    }
}

"Pembatasan" lainnya termasuk menafsirkan nama kunci tertentu seperti @meta dengan cara khusus dan menyediakan metode pelarian.

Objek kdb berisi kunci sebenarnya dan meta berisi metadata. (Catatan: untuk menyelesaikan kunci non-daun dengan nilai, Anda memerlukan objek lain)

Alih-alih dua objek JSON kita juga bisa menggunakan file terpisah. Tapi itu membutuhkan dukungan setidaknya dari resolver dan bahkan mungkin kode / plugin backend. File terpisah akan memungkinkan untuk mengimpor file JSON standar, tanpa metadata apa pun. Bagaimana kunci non-daun dengan nilai akan ditangani dalam kasus ini tidak jelas.

Sebagai pengguna saya lebih suka dapat mengimpor / mengekspor ke spesifikasi standar (kehilangan metadata) sambil menyimpan data nyata (termasuk metadata) menggunakan format internal elektra sewenang-wenang.

Saya setuju, tetapi mengimpor / mengekspor semuanya bertentangan dengan gagasan titik gunung Elektra.

Saya sudah tahu, tidak ada yang mau menerapkan ini, tetapi ada solusi yang sangat umum:

Jika mountpoint menggunakan plugin penyimpanan yang tidak mendukung semua fitur Elektra, plugin backend membuat file penyimpanan cadangan sekunder dalam format yang mendukung semua fitur (mis. quickdump , mmapstorage sepertinya membuang-buang ruang disk di sini). Saat menulis mountpoint seperti itu, kami cukup menulis dengan kedua plugin. Saat membaca, pertama-tama kita membaca file cadangan sekunder, lalu file utama. Ini akan membutuhkan proses penggabungan, tetapi kami akan mengambil file utama sebagai sumber sehingga penggabungannya cukup sederhana.

Saya pikir membatasi format bisa membingungkan pengguna.

Pastinya. Tetapi jelas bagi saya bahwa saat ini Elektra memungkinkan banyak dan sesuatu harus dibatasi.

Bahkan solusi dengan banyak file memerlukan beberapa jenis pembatasan pada nama file konfigurasi untuk menghindari benturan.

Awalnya saya pikir solusi termudah adalah membatasi Nama Kunci Elektra, karena itu adalah bagian yang paling kami kuasai. Namun ternyata ada aplikasi yang menggunakan WiFi SSID [1] secara langsung sebagai Key Name Part, sehingga tidak berfungsi. Setidaknya bukan tanpa usaha besar, seperti yang ditunjukkan proposal saya ...
IMO masih akan menjadi solusi terbaik untuk semua ini untuk hanya mengatakan "Key Nama Bagian yang tidak urutan sewenang-wenang non zero-byte lagi" dan dilakukan dengan hal itu. Sebagai perbandingan, POSIX hanya mengizinkan karakter berikut dalam nama file:

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -

Dan itu sepertinya cukup untuk orang-orang. Semua sistem file yang terdaftar di Wikipedia (kecuali yang tanpa direktori) memiliki semacam pembatasan pada nama file.

Saya ingin menekankan lagi: Semua ini bermuara pada fakta bahwa kami telah mengambil "Key Name Parts adalah urutan sembarang byte bukan nol" sebagai aksioma [2]. Mengubah ini akan sangat mudah dan akan memperbaiki segalanya. Bahkan bisa menjadi batasan kecil misalnya "Bagian Nama Kunci adalah urutan sembarang byte bukan nol, kecuali yang keduanya dimulai dengan @$% dan diakhiri dengan !%& pada waktu yang sama".
Hanya memesan satu Bagian Nama Kunci misalnya "Bagian Nama Kunci adalah urutan acak dari byte bukan nol, kecuali !@& bukan", akan memberi kita banyak kemungkinan. Heck, bahkan pembatasan "Bagian Nama Kunci terakhir dalam Nama Kunci tidak boleh diakhiri dengan @%& " sudah cukup. Segala jenis pembatasan [3] sekecil apapun akan memberi kita kelonggaran untuk menerapkan segala macam hal.
Tentu saja, banyak batasan memungkinkan solusi, tetapi solusi yang baik dan dapat digunakan mungkin memerlukan batasan yang lebih besar.

Maaf, jika ini tampak seperti kata-kata kasar, tetapi pada titik tertentu akan sangat membuat frustrasi karena semua orang setuju bahwa ada masalah, tetapi setiap solusi dianggap memiliki cacat atau dianggap terlalu rumit.

[1] Menurut Wikipedia hingga 802.11-2012, SSID WiFi adalah "nol hingga 32 oktet (32 byte) panjang" termasuk nol-byte dan "tumpukan jaringan nirkabel masih harus disiapkan untuk menangani nilai arbitrer di bidang SSID", bahkan meskipun SSID sekarang harus UTF-8 yang valid. Jadi hanya keyAddBaseName ing WiFi SSID tanpa logika tambahan tidak akan memenuhi standar standar.

[2] Itulah sebenarnya, mengapa dokumentasi baru di # 3447 dimulai dengan Key Name Parts. Paling mudah (dan IMO paling logis) untuk menjelaskan Nama Kunci saat ini dengan memulai dengan Bagian Nama Kunci dan pergi dari sana. Tapi cara lama

ambil jalur sistem file Unix / POSIX dan tambahkan namespace, tetapi juga ada hal khusus seperti bagian kosong dan ada urutan pelolosan, dan kemudian ada versi unescaped - itu semi-tersembunyi tetapi mungkin harus digunakan untuk semuanya selain mencetak - oh dan array adalah suatu hal, juga beberapa bagian dicadangkan tetapi sebenarnya tidak dicadangkan sehingga kami tidak benar-benar menggunakannya untuk apa pun tingkat rendah, ....

menunjukkan jauh lebih baik betapa rumit dan rumitnya Nama Kunci yang sangat rumit.

[3] Jika Anda bertanya-tanya, yes # 3447 memberlakukan beberapa batasan baru, tetapi itu tidak berguna, karena mereka tidak mempengaruhi Unescaped Key Name (kecuali untuk namespace) dengan cara apapun.

File terpisah akan memungkinkan untuk mengimpor file JSON standar, tanpa metadata apa pun. Bagaimana kunci non-daun dengan nilai akan ditangani dalam kasus ini tidak jelas.

Kami membahas hal ini mengenai implementasi cache dan memutuskan untuk tidak melakukannya. Implementasi resolver saat ini memiliki jaminan konsistensi yang lebih kuat daripada yang dapat dicapai saat menggunakan dua file. Penyelesai menggunakan fungsi atomic rename() untuk memastikan bahwa suatu proses membaca file lama atau baru, tetapi selalu konsisten. Sayangnya ini tidak dapat (sepengetahuan saya) dilakukan dengan banyak file sambil memiliki jaminan yang sama. Saya akan enggan menggunakan banyak file di mana kita perlu memastikan konsistensi.

Saya setuju, tetapi mengimpor / mengekspor semuanya bertentangan dengan gagasan titik gunung Elektra.

Benar.

Semua ini bermuara pada fakta bahwa kami telah mengambil "Bagian Nama Kunci adalah urutan sembarang byte bukan nol" sebagai aksioma [2].

Saya setuju, ini adalah bagian di mana pembatasan paling masuk akal. Seperti yang Anda katakan, nama file cukup dibatasi dan masih berfungsi dengan baik. Kecuali ada yang tahu alasan yang bagus untuk tidak membatasi nama kunci (mungkin @ markus2330)?

Maaf, jika ini tampak seperti kata-kata kasar

Tidak, dan terima kasih telah membahas ini. Kecuali @ markus2330 mengetahui beberapa alasan mengapa kami tidak dapat mengubah ini, saya sepenuhnya terbuka untuk saran Anda (seperti membatasi !@& ).

Saya akan enggan menggunakan banyak file di mana kita perlu memastikan konsistensi.

Itu alasan yang bagus, terhadap banyak file ya ...

Saya sepenuhnya terbuka untuk saran Anda (seperti membatasi !@& ).

Lebih realistisnya kita bisa memberlakukan batasan: "Nama Kunci tidak boleh mengandung Bagian Nama Kunci @elektra " (mungkin awalan yang lebih tidak jelas, jika itu membantu). Saya pikir menggunakan elektra mungkin membuat semuanya sedikit lebih masuk akal bagi pengguna.

Secara pribadi, saya pikir kita harus meninggalkan ruang untuk masa depan, tetapi jika membatasi semua Nama Kunci terlalu banyak, kita juga dapat membatasi apa yang dapat dikembalikan kdbGet dan apa yang dapat diterima kdbSet . Jadi batasan di atas hanya akan berlaku untuk plugin terakhir selama kdbGet dikembalikan dan KeySet diberikan ke kdbSet . Pada dasarnya kami hanya membatasi Kunci apa yang dapat disimpan dari sudut pandang aplikasi. Ini akan mirip dengan apa yang sudah kita miliki dengan system:/elektra (walaupun kali ini kita benar-benar memberlakukan pembatasan).

Terima kasih banyak atas diskusi yang berharga ini. Saya memulai # 3514 untuk meringkas keputusan penting yang tersebar di mana-mana. Silakan lebih suka untuk langsung mengomentari teks di # 3514, sehingga kami dapat mengambil kesimpulan.

Bagian @value adalah ya. Tapi itu lebih umum. @meta dapat digunakan untuk menyimpan metadata di dalam format dengan struktur objek bertingkat tunggal, seperti JSON atau TOML (masih belum yakin tentang YAML, karena tag).
Pada dasarnya, karena semua yang ada di file JSON mengacu pada beberapa kunci di suatu tempat, tidak ada tempat untuk menyimpan metadata.

Saya tidak berpikir lagi bahwa itu harus menjadi tujuan kami untuk menghindari pembatasan format file. Jika JSON tidak mendukung nilai meta-data dan non-leaf, Elektra dengan file JSON terpasang, cukup teruskan pembatasannya pada KeySets. Kita dapat mendokumentasikannya, seperti yang diusulkan pada # 3504 dan plugin penyimpanan akan gagal pada KeySets tersebut tetapi tidak lebih. (Tentu saja seseorang dapat membuat format file super-JSON dengan lebih sedikit batasan tetapi ini di luar tenaga kami saat ini dan dengan demikian tidak relevan.)

tetapi aplikasi yang menggunakan @ di awal kolom JSON mungkin cukup jarang.

Siapa tahu?

keyAddBaseName (k, "@abc") berfungsi di kedua kasus, satu-satunya perbedaan adalah nama yang di-escape yang dibuatnya.

Kedengarannya bagus.

tapi setidaknya ketika Anda sampai ke metadata, itu rusak untuk format tertentu.

Ya, kita perlu membuang gagasan bahwa format apa pun dapat mendukung apa pun.

Tidak jelas bagi saya bagaimana pengguna dapat memeriksa bahwa file konfigurasinya sesuai dengan spesifikasi yang dibatasi.

Saya pikir sebagian besar aplikasi tidak akan terlalu menuntut (misalnya hanya memiliki nilai daun dan tidak memerlukan meta-data kecuali jenis), jadi semua yang kita bahas di sini hanya relevan untuk aplikasi luar biasa. Untuk aplikasi ini, menurut saya yang terbaik adalah pengembang aplikasi mengembangkan plugin penyimpanan mereka sendiri atau mereka menggunakan plugin penyimpanan terbaik kami, yang mendukung hal-hal seperti itu.

@ markus2330 apa pendapat Anda tentang penerapan pembatasan pada format?

Itu bukan ide yang bagus. Kami harus mendukung format file konfigurasi sebagai standar. Ini bisa menjadi masalah besar jika beberapa file JSON / XML yang valid ditolak oleh Elektra. Namun di sisi lain, kami tidak perlu mendukung apa pun selain standar. Mencoba ini adalah kesalahan dari masa lalu (mencoba menyenangkan siapa pun).

Kita perlu menentukan prioritas kita. Apa sebenarnya yang mutlak harus, dan di mana hal-hal bisa berubah.

doc / GOALS.md di # 3514

Bagian terburuknya adalah penyalahgunaan bagian yang tidak boleh disentuh oleh parser dan secara drastis dapat mempengaruhi keterbacaan file penyimpanan.

Saya setuju ini bukan ide terbaik, sudah ada banyak masalah di plugin ini . badcec5407df6947a67750afd8f0946245c5a5bb

Alih-alih dua objek JSON kita juga bisa menggunakan file terpisah.

Lihat di bawah.

Sebagai perbandingan, POSIX hanya mengizinkan karakter berikut dalam nama file:

Ini adalah "Kumpulan Karakter Nama File portabel" dan saya ragu apakah ada sistem file yang digunakan lagi yang hanya mendukung ini. Dalam pengalaman saya, interpretasi apa pun dari nama file hanya menimbulkan masalah (misalnya JFS memiliki fitur seperti itu).

Dan itu sepertinya cukup untuk orang-orang.

Untuk sumber Elektra, ini hampir # 1615: wink:

Tetapi aplikasi nyata segera menginginkan lebih ... (misalnya spasi, umlaut, ....)

Mengubah ini akan sangat mudah dan akan memperbaiki segalanya.

Ini tidak sesederhana itu: ini membuat plugin penyimpanan jauh lebih rumit. Itu hanya memindahkan logika ke tempat lain.

kecuali yang keduanya dimulai dengan @ $% dan diakhiri dengan!% & pada waktu yang sama

Ide ini mirip dengan CDATA . Ini bukan solusi yang bagus dan tidak berguna untuk digunakan dalam praktik.

HERE dokumen sedikit lebih baik, karena pengguna dapat menentukan urutan pelolosan.

Tetapi untuk fitur apa sebenarnya yang menurut Anda kami membutuhkannya? Saya pikir kita sebaiknya melupakan fitur-fitur ini dan menggunakan meta-data dengan benar untuk memberikan semantik ke kunci.

Maaf, jika ini tampak seperti kata-kata kasar, tetapi pada titik tertentu akan sangat membuat frustrasi karena semua orang setuju bahwa ada masalah, tetapi setiap solusi dianggap memiliki cacat atau dianggap terlalu rumit.

Maksud saya adalah: mungkin kita tidak membutuhkan solusi karena masalahnya tidak ada.

sekarang harus UTF-8 yang valid

Bisakah mereka tetap memiliki karakter nol? Btw. Saya mendapatkan contoh SSID karena ini adalah persyaratan nyata dari pelanggan nyata (broadcom). Karakter nol tidak diperlukan, jelas bahwa char* tanpa ukuran tidak dapat mendukung ini, jadi kami bahkan tidak membahas tentang ini.

menunjukkan jauh lebih baik betapa rumit dan rumitnya Nama Kunci yang sangat rumit.

Ya, tetapi lebih baik mereka seperti ini daripada memiliki logika seperti itu di setiap aplikasi dan plugin penyimpanan.

Jika Anda bertanya-tanya, ya # 3447 memberlakukan beberapa batasan baru

Ya, nama kunci dapat memiliki batasan apa pun. Selalu ada batasan pelarian yang menggantung, jadi beberapa batasan lagi tidak masalah. # 3447 akan menjadi peningkatan besar bagi Elektra.

Sayangnya ini tidak dapat (sepengetahuan saya) dilakukan dengan banyak file sambil memiliki jaminan yang sama

Ini dapat dilakukan dengan menulis log jurnal di mana Anda menulis semua yang Anda rencanakan dan jika ada masalah, Anda dapat memulihkannya dengan memutar ulang jurnal. Untuk menerapkan ini jauh di luar tenaga kami. Ini juga tidak benar-benar sesuai dengan sistem konfigurasi (atau sistem file), ini adalah teknik untuk database terstruktur.

Saya menjadikannya bukan tujuan di multiple_file_backends.md 59066aa99bae707d0f0178841513fd3b8590b5bc

Pada dasarnya kami hanya membatasi Kunci apa yang dapat disimpan dari sudut pandang aplikasi. Ini akan serupa dengan apa yang sudah kita miliki dengan system: / elektra (meskipun kali ini kami benar-benar memberlakukan pembatasan).

Kita bisa memberlakukan batasan system:/elektra . Tetapi mengapa Anda ingin membatasi aplikasi apa yang menyimpan di bagian hierarki mereka?

Saya pikir yang terbaik adalah pengembang aplikasi mengembangkan plugin penyimpanan mereka sendiri

Dengan demikian mengalahkan salah satu manfaat utama Elektra: "Admin / pengguna memutuskan format konfigurasi bukan pengembang aplikasi".

Ini bisa menjadi masalah besar jika beberapa file JSON / XML yang valid ditolak oleh Elektra

Itu tidak pernah menjadi saran saya. Tentu saja kami harus menerima setiap JSON yang valid. Pertanyaannya adalah KeySet apa yang kita hasilkan. Jika kami menggunakan "@value" untuk nilai non-daun seperti yang disarankan di atas, kami masih dapat menerima setiap JSON yang valid. Hasil KeySet hanya akan memiliki struktur yang sedikit berbeda pada suatu waktu.

Sebagai perbandingan, POSIX hanya mengizinkan karakter berikut dalam nama file:

Ini adalah "Kumpulan Karakter Nama File portabel" dan saya ragu apakah ada sistem file yang digunakan lagi yang hanya mendukung ini. Dalam pengalaman saya, interpretasi apa pun dari nama file hanya menimbulkan masalah (misalnya JFS memiliki fitur seperti itu).

Dan itu sepertinya cukup untuk orang-orang.

Untuk sumber Elektra, nilainya hampir # 1615

Tetapi aplikasi nyata segera menginginkan lebih ... (misalnya spasi, umlaut, ....)

Mereka masih tidak mengizinkan / atau nama kosong. Kebanyakan juga memiliki panjang maksimum untuk nama file dan jalur. Intinya adalah aplikasi menemukan cara untuk mengatasi keterbatasan. Dan dalam kasus kami, kami bahkan dapat membantu mereka dengan perpustakaan.

Ini tidak sesederhana itu: ini membuat plugin penyimpanan jauh lebih rumit. Itu hanya memindahkan logika ke tempat lain.

Saya tidak setuju. Plugin penyimpanan sudah sangat kompleks, secara relatif ini hanya akan menjadi ketidaknyamanan kecil. (dengan asumsi kami menyediakan perpustakaan storage dengan fungsi pembantu)

Ide ini mirip dengan CDATA. Ini bukan solusi yang bagus dan tidak berguna untuk digunakan dalam praktik.

Dokumen HERE sedikit lebih baik, karena pengguna dapat menentukan urutan pelolosan.

Baik CDATA dan HERE dokumen perlu menyimpan beberapa sintaks, dari sudut pandang Elektra saat ini tidak ada perbedaan. Kedua versi tersebut merupakan batasan pada nama kunci.

Juga keduanya _much_ lebih kuat dari yang saya usulkan. Proposal saya hanya akan "lolos" dari bagian nama kunci lengkap pada satu waktu.

Saya pikir kita sebaiknya melupakan fitur-fitur ini dan menggunakan meta-data dengan benar untuk memberikan semantik ke kunci.

Anda baru saja mengatakan, bahwa beberapa plugin penyimpanan mungkin tidak mendukung metadata. Jadi sepertinya ini bukan pilihan.

Maksud saya adalah: mungkin kita tidak membutuhkan solusi karena masalahnya tidak ada.

Tentu saja, jika Anda berubah pikiran dan mengatakan format penyimpanan dapat membatasi kemampuan Elektra, masalahnya akan hilang. Tapi itu secara fundamental mengubah janji Elektra kepada pengguna. Kami akan membatasi semua pengguna hanya untuk mengizinkan beberapa pengembang untuk mengamankan beberapa baris kode yang berhubungan dengan pengkodean nilai khusus.

Bisakah mereka tetap memiliki karakter nol?

Mungkin, NUL adalah karakter UTF-8 yang valid.

tanpa ukuran tidak dapat mendukung ini

Nah, ukuran maksimum SSID adalah 32 byte, jadi Anda tidak perlu meneruskan ukuran tersebut, selama buffer selalu 32 byte dan tanpa bantalan.

Ya, nama kunci dapat memiliki batasan apa pun.

Tolong buat keputusanmu. Selama ini Anda berpendapat bahwa tidak mungkin ada batasan.

Selalu ada batasan pelarian yang menggantung, jadi beberapa batasan lagi tidak masalah.

"Menggantung pelarian" bukanlah batasan. Ini adalah kesalahan sintaks dalam nama kunci yang di-escape. Nama kunci yang lolos tidak pernah menjadi string arbitrer. Ini adalah hal yang sama sekali berbeda.

Kita dapat memberlakukan pembatasan system:/elektra .

Kami mungkin memerlukan tanda di keyNew untuk mengizinkan nama seperti itu. Jika tidak, aplikasi yang menerima nama kunci dari pengguna, harus membersihkan input. Lihat juga masalah kdb import di # 3299.

Tetapi mengapa Anda ingin membatasi aplikasi apa yang menyimpan di bagian hierarki mereka?

Saya tidak ingin membatasi aplikasi _what_ disimpan, tetapi _bagaimana_ mereka menyimpannya. Ini memberi plugin (penyimpanan) lebih banyak kebebasan.

Dengan demikian mengalahkan salah satu manfaat utama Elektra: "Admin / pengguna memutuskan format konfigurasi bukan pengembang aplikasi".

Tidak mungkin plugin penyimpanan apa pun dapat digunakan untuk aplikasi apa pun. Ini tidak berarti bahwa kami menarik kekuatan admin / pengguna untuk mengubah mountpoint. Tetapi kita harus jujur ​​dan memberikan penyangkalan besar bahwa melakukan hal itu melibatkan beberapa risiko.

Itu tidak pernah menjadi saran saya. Tentu saja kami harus menerima setiap JSON yang valid. Pertanyaannya adalah KeySet apa yang kami produksi. Jika kami menggunakan "@value" untuk nilai non-daun seperti yang disarankan di atas, kami masih dapat menerima setiap JSON yang valid. KeySet yang dihasilkan terkadang memiliki struktur yang sedikit berbeda.

Mengenai masalah ini kami telah menghabiskan banyak waktu dalam waktu sekitar 10 tahun, tanpa kemajuan apa pun. Ide pertama adalah keytometa, lalu nilai direktori, dengan banyak langkah di antaranya. Mengapa tidak menerima JSON apa adanya? Ini akan bekerja untuk sebagian besar aplikasi. Apakah struktur yang sedikit lebih baik sangat berharga?

Intinya adalah aplikasi menemukan cara untuk mengatasi keterbatasan.

Aplikasi bahkan menemukan cara untuk mengatasi ketiadaan pustaka konfigurasi. Mengapa mereka menggunakan pustaka konfigurasi yang memberi mereka batasan yang saat ini tidak mereka miliki? Sangat mudah untuk mengimplementasikan file properti yang mengizinkan nama kunci dengan nilai apa pun. Mengapa Elektra akan berguna jika tidak memberikan ini?

Dan dalam kasus kami, kami bahkan dapat membantu mereka dengan perpustakaan.

Pertama kita perlu memperjelas tujuan sebelum kita membuat solusi yang kompleks.

Saya tidak setuju. Plugin penyimpanan sudah sangat kompleks,

Apakah Anda melihat simpleini, ni, c atau mini? Anda masih dapat dengan mudah menulis plugin penyimpanan yang berguna dalam waktu kurang dari sehari.

relatif berbicara ini hanya akan menjadi ketidaknyamanan kecil. (dengan asumsi kami menyediakan pustaka penyimpanan yang baik dengan fungsi pembantu)

Sayangnya anggapan itu tidak berlaku. Kami juga mencoba membuat perpustakaan pembantu sejak bertahun-tahun, dengan sedikit keberhasilan. Apa yang dilakukan di dalam inti dengan baik selalu merupakan solusi terbaik.

Baik dokumen CDATA dan HERE perlu mencadangkan beberapa sintaks, dari sudut pandang Elektra saat ini tidak ada perbedaan. Kedua versi tersebut merupakan batasan pada nama kunci.

Tidak, dokumen HERE tidak memiliki sintaks apa pun. Anda dapat memutuskan dengan cepat (misalnya berdasarkan data) kata kunci mana yang ingin Anda gunakan untuk menandai akhir dokumen.

Saya pikir kita sebaiknya melupakan fitur-fitur ini dan menggunakan meta-data dengan benar untuk memberikan semantik ke kunci.
Anda baru saja mengatakan, bahwa beberapa plugin penyimpanan mungkin tidak mendukung metadata. Jadi sepertinya ini bukan pilihan.

Cara yang benar adalah dengan menentukan kunci dalam namespace spec . Plugin penyimpanan di ruang nama lain tidak perlu menyimpan metadata apa pun. Lihat keputusan arbitrary_metadata.md di # 3514

Tentu saja, jika Anda berubah pikiran dan mengatakan format penyimpanan dapat membatasi kemampuan Elektra, masalahnya akan hilang. Tapi itu secara fundamental mengubah janji Elektra kepada pengguna. Kami akan membatasi semua pengguna hanya untuk mengizinkan beberapa pengembang untuk mengamankan beberapa baris kode yang berhubungan dengan pengkodean nilai khusus.

Saya memisahkan pertanyaan ini dengan # 3515

Ya, nama kunci dapat memiliki batasan apa pun.
Tolong buat keputusanmu. Selama ini Anda berpendapat bahwa tidak mungkin ada batasan.

Nama kunci alias keySetName dapat memiliki batasan (yaitu gagal untuk beberapa argumen), nama bagian kunci alias keySetBaseName tidak dapat memiliki batasan (tidak pernah gagal pada argumen apa pun). Saya tidak fanatik atau dogmatis, kita bisa membahas ini dan yang lainnya jika Anda melihat masalah mendasar dengan tujuan kita yang paling penting.

Kami dapat memberlakukan pembatasan sistem: / elektra.
Kita bisa memerlukan flag di keyNew untuk mengizinkan nama seperti itu. Jika tidak, aplikasi yang menerima nama kunci dari pengguna, harus membersihkan input.

Saya sedang memikirkan sebuah plugin yang menolak apa pun yang ditulis ke /elektra yang tidak mengkonfirmasi alat apa yang diizinkan untuk menulis di sana. Saya pikir ini adalah prioritas rendah.

Tidak, dokumen HERE tidak memiliki sintaks apa pun. Anda dapat memutuskan dengan cepat (misalnya berdasarkan data) kata kunci mana yang ingin Anda gunakan untuk menandai akhir dokumen.

Ya, mereka melakukan << masih dicadangkan untuk memulai dokumen HERE. Penanda akhir ditentukan pengguna, tetapi awalnya jelas tidak bisa.
Bagaimanapun, ini tidak penting.

Tidak mungkin plugin penyimpanan apa pun dapat digunakan untuk aplikasi apa pun.

Tidak masalah bagi saya, jika tidak semua plugin mendukung semuanya, tetapi jika aplikasi menggunakan plugin penyimpanan kustom, admin / pengguna tidak punya pilihan. Setidaknya harus ada beberapa pilihan, meskipun hanya misalnya YAML atau TOML. Jika hanya format kustom yang disesuaikan dengan Elektra yang mendukung semuanya, maka saya khawatir tidak akan ada yang menggunakan Elektra. Bagi saya, salah satu fitur Elektra yang paling penting adalah bahwa amdin / pengguna selalu dapat menggunakan format konfigurasi favorit mereka apa pun aplikasinya.

Apakah Anda melihat simpleini, ni, c atau mini? Anda masih dapat dengan mudah menulis plugin penyimpanan yang berguna dalam waktu kurang dari sehari.

c adalah hanya tulis. mini tidak mendukung metadata dan AFAICT menghapus semua komentar dari sebuah file. simpleini juga tidak mendukung metadata dan mencantumkan lebih banyak batasan di README.

Secara umum, plugin INI bukanlah contoh yang baik, karena INI tidak benar-benar memiliki spesifikasi, jadi tidak ada batasan yang berasal dari formatnya.

ni didasarkan pada pustaka yang ada. Itulah mengapa kodenya cukup pendek dan sederhana.

Tapi ni sebenarnya adalah contoh yang sangat bagus tentang apa yang ingin saya lakukan. Ini menggunakan interpretasi yang sangat spesifik dari file INI yang mungkin tidak diinginkan oleh pengembang aplikasi. Ini sebenarnya menimbulkan pertanyaan lain.

Apa kasus penggunaan yang lebih penting?

1. Mengonversi aplikasi yang ada ke Elektra dan menjaga file konfigurasinya tetap sama
2. Menulis aplikasi baru yang format konfigurasinya akan didasarkan pada apa yang paling cocok untuk Elektra

Untuk kasus pertama, kita membutuhkan plugin yang dapat membaca file apapun dan menghasilkan KeySet s yang berguna.
Untuk kasus kedua, bahkan pembatasan berat seperti yang diberlakukan oleh ni mungkin tidak menjadi masalah.

Cara yang tepat adalah menentukan kunci dalam namespace spec . Plugin penyimpanan di ruang nama lain tidak perlu menyimpan metadata apa pun.

Ya, ini adalah solusi yang mungkin. Tetapi membutuhkan banyak usaha untuk membuat spec berfungsi dengan baik. Paling tidak, kita memerlukan jaminan pemesanan plugin dalam posisi postgetstorage .

Tetapi hal itu menyebabkan beberapa kesulitan dengan metadata yang disimpulkan dari format penyimpanan (mis. Tipe, larik). Apakah ini akan menjadi kesalahan, jika kita membaca array JSON yang tidak cocok dengan array metadata di spec ?

Namun, ini tidak menyelesaikan masalah untuk kunci non-daun dengan nilai.

Nama kunci alias keySetName dapat memiliki batasan (misalnya gagal untuk beberapa argumen), nama bagian kunci alias keySetBaseName tidak dapat memiliki batasan (tidak pernah gagal pada argumen apa pun).

Ini adalah dua hal yang sangat berbeda. keySetName menerima nama kunci yang di- escape , sedangkan keySetBaseName menerima bagian dari nama kunci yang tidak di -

Namun, segala sesuatu di sekitar nama kunci Elektra didasarkan pada nama _key part_ (lihat juga dokumen di # 3447). Jadi satu-satunya pertanyaan yang perlu kita diskusikan adalah:

_Apa itu bagian nama kunci? _

Tidak masalah bagi saya, jika tidak semua plugin mendukung semuanya, tetapi jika aplikasi menggunakan plugin penyimpanan kustom, admin / pengguna tidak punya pilihan.

Saya tidak melihat bagaimana ini mungkin terjadi. Di Elektra Anda selalu dapat mengimplementasikan alternatif selama alternatif ini menghasilkan KeySet yang sesuai untuk aplikasi tersebut. Satu-satunya hal yang diperbaiki adalah KeySet tetapi bagaimana KeySet diproduksi selalu merupakan sesuatu yang dapat dipertukarkan. Bagi saya inilah manfaat utama Elektra.

Itulah mengapa KeySet (termasuk nama-nama kunci) adalah keputusan yang paling penting (dan paling sulit) dari semuanya.

Setidaknya harus ada beberapa pilihan, meskipun hanya misalnya YAML atau TOML. Jika hanya format kustom yang disesuaikan dengan Elektra yang mendukung semuanya, maka saya khawatir tidak akan ada yang menggunakan Elektra. Bagi saya, salah satu fitur Elektra yang paling penting adalah bahwa amdin / pengguna selalu dapat menggunakan format konfigurasi favorit mereka apa pun aplikasinya.

Saya tidak melihat bagaimana keputusan yang kita bicarakan mempengaruhi kemungkinan. Jika Anda berusaha cukup keras untuk membuat plugin penyimpanan untuk format konfigurasi favorit Anda (termasuk ekstensi sintaksis atau yang serupa), Anda akan dapat menjalankan aplikasi apa pun.

mini tidak mendukung metadata dan AFAICT menghapus semua komentar dari sebuah file. simpleini juga tidak mendukung metadata dan mencantumkan lebih banyak batasan di README.

Untuk sebagian besar aplikasi, pembatasan ini tidak relevan. Satu alat yang saya gunakan bekerja dengan simpleini dan juga mini sebagai backend.

Saya pikir kita sudah sampai pada kesimpulan yang sama: Apa pun yang terjadi untuk menghasilkan KeySet yang benar, harus terjadi di dalam plugin penyimpanan. Menggunakan "pustaka penyimpanan" tentu saja menguntungkan, tetapi pada akhirnya ini adalah detail implementasi. Gagasan bahwa "plugin kemudian memperbaiki kesalahan plugin penyimpanan". Jadi mengapa kita membutuhkan sintaks lebih lanjut pada nama kunci? Sintaks apa pun yang diperlukan dapat dihilangkan dalam plugin penyimpanan.

1. Mengonversi aplikasi yang ada ke Elektra dan menjaga file konfigurasinya tetap sama
2. Menulis aplikasi baru yang format konfigurasinya akan didasarkan pada apa yang paling cocok untuk Elektra

Imho "1." lebih penting sekarang, karena kita membutuhkan ini untuk KDE. Jadi entah bagaimana kita membutuhkan Elektra agar tidak merusak plugin kconfig .

Tentang "2." Saya tidak tahu apa artinya "paling cocok untuk Elektra". Elektra tidak memiliki tujuan untuk dirinya sendiri, satu-satunya tujuan adalah untuk melayani kebutuhan pengembang, pengguna, dan admin.

Tetapi hal itu menyebabkan beberapa kesulitan dengan metadata yang disimpulkan dari format penyimpanan (mis. Tipe, larik). Apakah ini akan menjadi kesalahan, jika kita membaca array JSON yang tidak memiliki metadata array yang cocok dalam spesifikasi?

Tidak, hanya kesalahan yang terjadi sebaliknya: jika spesifikasi memerlukan array tetapi tidak ada.

Ya, ini adalah solusi yang mungkin. Tetapi membutuhkan banyak pekerjaan untuk membuat spesifikasi berfungsi dengan baik. Paling tidak, kami memerlukan jaminan pemesanan plugin dalam posisi pascapemeliharaan.

Ya, saya sangat setuju. Dan sesuatu perlu dilakukan dengan spec bagaimanapun juga, kita tidak bisa membiarkannya apa adanya.

Namun, ini tidak menyelesaikan masalah untuk kunci non-daun dengan nilai.

Anda berpendapat bahwa ini tidak penting: stuck_out_tongue_winking_eye:

Dan saya setuju, untuk hampir semua aplikasi itu tidak penting.

Apa itu bagian nama kunci?

Bisakah Anda membuat masalah yang mencantumkan poin terbuka / tidak jelas? Atau bahkan lebih baik: tambahkan ke # 3514?

Tidak masalah bagi saya, jika tidak semua plugin mendukung semuanya, tetapi jika aplikasi menggunakan plugin penyimpanan kustom, admin / pengguna tidak punya pilihan.

Saya tidak melihat bagaimana ini mungkin terjadi. Di Elektra Anda selalu dapat mengimplementasikan alternatif selama alternatif ini menghasilkan KeySet yang sesuai untuk aplikasi tersebut. Satu-satunya hal yang diperbaiki adalah KeySet tetapi bagaimana KeySet diproduksi selalu merupakan sesuatu yang dapat dipertukarkan. Bagi saya inilah manfaat utama Elektra.

Itulah mengapa KeySet (termasuk nama-nama kunci) adalah keputusan yang paling penting (dan paling sulit) dari semuanya.

Setidaknya harus ada beberapa pilihan, meskipun hanya misalnya YAML atau TOML. Jika hanya format kustom yang disesuaikan dengan Elektra yang mendukung semuanya, maka saya khawatir tidak akan ada yang menggunakan Elektra. Bagi saya, salah satu fitur Elektra yang paling penting adalah bahwa amdin / pengguna selalu dapat menggunakan format konfigurasi favorit mereka apa pun aplikasinya.

Saya tidak melihat bagaimana keputusan yang kita bicarakan mempengaruhi kemungkinan. Jika Anda berusaha cukup keras untuk membuat plugin penyimpanan untuk format konfigurasi favorit Anda (termasuk ekstensi sintaksis atau yang serupa), Anda akan dapat menjalankan aplikasi apa pun.

>

Saya seharusnya menambahkan lebih banyak konteks ke tanggapan saya. Saya pikir kita berada di halaman dalam hal ini. Komentar saya adalah menanggapi pernyataan Anda ini:

Saya pikir sebagian besar aplikasi tidak akan terlalu menuntut (misalnya hanya memiliki nilai daun dan tidak memerlukan meta-data kecuali jenis), jadi semua yang kita bahas di sini hanya relevan untuk aplikasi luar biasa. Untuk aplikasi ini, menurut saya yang terbaik adalah pengembang aplikasi mengembangkan plugin penyimpanan mereka sendiri atau mereka menggunakan plugin penyimpanan terbaik kami, yang mendukung hal-hal seperti itu.

Khususnya bagian: "Menurut saya, yang terbaik adalah pengembang aplikasi mengembangkan plugin penyimpanan mereka sendiri"

Meskipun ini akan selalu menjadi pilihan, saya pikir itu harus _never_ menjadi sesuatu yang kami rekomendasikan atau bahkan sarankan sebagai solusi. Menggunakan plugin penyimpanan khusus tidak akan sejalan dengan filosofi Elektra dan harus dihindari sejauh mungkin. Catatan: dengan "plugin penyimpanan khusus" yang saya maksud adalah plugin yang dirancang untuk bekerja dengan aplikasi tertentu tetapi tidak ada jaminan untuk kompatibel dengan Elektra lainnya. Tidak apa-apa, jika seseorang ingin menggunakan format kustom dan mengembangkan plugin yang sesuai yang kompatibel dengan lingkungan Elektra standar.

Saya pikir kita sudah sampai pada kesimpulan yang sama: Apa pun yang terjadi untuk menghasilkan KeySet yang benar, harus terjadi di dalam plugin penyimpanan. Menggunakan "pustaka penyimpanan" tentu saja menguntungkan, tetapi pada akhirnya ini adalah detail implementasi. Gagasan bahwa "plugin kemudian memperbaiki kesalahan plugin penyimpanan".

Ya, pada dasarnya itu. Plugin penyimpanan tidak dapat mengandalkan plugin lain (kecuali mungkin nilai biner dan hal semacam itu).

Meskipun mungkin plugin sebenarnya adalah solusinya. Saya harus memikirkannya lebih jauh dan akan memposting idenya, jika menurut saya berhasil.

Tetapi hal itu menyebabkan beberapa kesulitan dengan metadata yang disimpulkan dari format penyimpanan (mis. Tipe, larik). Apakah ini akan menjadi kesalahan, jika kita membaca array JSON yang tidak memiliki metadata array yang cocok dalam spesifikasi?

Tidak, hanya kesalahan yang terjadi sebaliknya: jika spesifikasi memerlukan array tetapi tidak ada.

Mari melangkah lebih jauh. Bagaimana jika kita memiliki JSON [ "a", "b" ] tanpa spesifikasi dan mengekspornya ke dalam format tanpa metadata dan tanpa array (mis. mini )? Informasi bahwa ini adalah larik akan hilang.

Karena ini adalah kasus tepi, kita mungkin hanya mengatakan: Ini sangat disayangkan, tetapi memang demikian adanya.

Dan saya setuju, untuk hampir semua aplikasi itu tidak penting.

Hal yang sama dapat dikatakan tentang penggunaan nama kunci arbitrer. Hampir semua aplikasi tidak akan bermasalah, jika mereka tidak dapat menggunakan /@elektra/ dalam nama kunci mereka.

Bisakah Anda membuat masalah yang mencantumkan poin terbuka / tidak jelas? Atau bahkan lebih baik: tambahkan ke # 3514?

Saya akan membuat daftar di suatu tempat, sehingga kita bisa membahasnya pada hari Senin.

Tidak apa-apa, jika seseorang ingin menggunakan format kustom dan mengembangkan plugin yang sesuai yang kompatibel dengan lingkungan Elektra standar.

Saya sebenarnya berpikir seperti ini. Tapi ya, kekhususan dengan mudah masuk. Misalnya plugin kconfig metadata hanya bisa satu karakter sehingga jelas tidak terlalu kompatibel dengan metadata kita (setidaknya selama parser tidak memetakan ulang karakter ini untuk arti sebenarnya, yang saat ini tidak terjadi). Saat ini kami hanya meneruskan metadata satu karakter melalui lapisan kami dan, jika perlu, lakukan di pustaka kconfig apa yang akan terjadi jika itu akan langsung mengurai file.

@mpranj apakah Anda sudah memeriksa apakah ini benar-benar berfungsi? Setidaknya [$e] tampaknya cukup sering ada.

Meskipun mungkin plugin sebenarnya adalah solusinya. Saya harus memikirkannya lebih jauh dan akan memposting idenya, jika menurut saya berhasil.

Saat ini saya lebih suka jika kita memperbaiki hal-hal yang sudah kita ketahui cara memperbaikinya.

Karena ini adalah kasus tepi, kita mungkin hanya mengatakan: Ini sangat disayangkan, tetapi memang demikian adanya.

Tepatnya, jika Anda menginginkan "fitur X", Anda tidak dapat memiliki plugin tanpa fitur ini dalam rantai impor / ekspor. Begitu pula dengan komentar dan sebagainya.

kunci non-daun dengan nilai.
Hal yang sama dapat dikatakan tentang penggunaan nama kunci arbitrer. Hampir semua aplikasi tidak akan bermasalah, jika mereka tidak dapat menggunakan / @ elektra / dalam nama kuncinya.

Iya. Tetapi ada juga perbedaan besar antara sesuatu yang tidak berfungsi dengan beberapa plugin dan sesuatu yang tidak akan pernah berfungsi sama sekali dengan Elektra.

Saya akan membuat daftar di suatu tempat, sehingga kita bisa membahasnya pada hari Senin.

: +1:

Tetapi ada juga perbedaan besar antara sesuatu yang tidak berfungsi dengan beberapa plugin dan sesuatu yang tidak akan pernah berfungsi sama sekali dengan Elektra.

Saya mengerti maksud Anda, tetapi secara realistis seberapa sering tidak memiliki kunci /@elektra/ benar-benar menjadi masalah?

Meskipun mungkin plugin sebenarnya adalah solusinya. Saya harus memikirkannya lebih jauh dan akan memposting idenya, jika menurut saya berhasil.

Saat ini saya lebih suka jika kita memperbaiki hal-hal yang sudah kita ketahui cara memperbaikinya.

Idenya adalah sebuah plugin yang selalu di-mount dan melakukan beberapa encoding / decoding nama kunci. Maka plugin penyimpanan hanya harus berurusan dengan KeySet s yang misalnya tidak berisi kunci /@elektra/ . Tetapi karena pengkodean aplikasi masih dapat menggunakan nama kunci apa saja. Plugin penyimpanan kemudian dapat menggunakan kunci /@elektra/ untuk tujuannya sendiri, misalnya nilai metadata dan non-daun.

Efeknya akan menjadi batasan kecil pada file penyimpanan, tetapi tidak ada batasan untuk aplikasi. Kompleksitas plugin penyimpanan juga tidak akan terpengaruh, karena plugin penyimpanan tidak harus menggunakan kunci /@elektra/ . Hanya plugin yang ingin mendukung mis. Metadata harus menulis kode tambahan, tetapi itu selalu terjadi.

Saya mengerti maksud Anda, tetapi secara realistis seberapa sering / @ elektra / keys tidak benar-benar menjadi masalah?

Mungkin tidak ada masalah sama sekali. Tapi itu akan menjadi masalah sekarang dan nanti. Jadi mengapa memesannya sekarang dan tidak ketika kami benar-benar menemukan kasus penggunaan di mana hal seperti ini dibutuhkan? Maka kita tahu itu bukan hanya fantasi dan bisa memilih nama yang sesuai.

Dalam bahasa pemrograman kami (biasanya) hanya menyimpan kata-kata kunci ketika kami benar-benar melakukan ekstensi sintaksis.

misalnya metadata

Untuk metadata pada kunci, spesifikasi adalah solusi yang lebih baik karena mengacu pada semua ruang nama. Metadata non-spesifikasi pada dasarnya hanyalah pemformatan yang berguna dan serupa.

karena plugin penyimpanan tidak harus menggunakan / @ elektra / keys

Ini bukan karena plugin penyimpanan menggunakan nama apa pun, pertanyaannya adalah perilaku jika menemukan <strong i="14">@elektra</strong> = something dalam sebuah file.

Jadi mengapa memesannya sekarang dan tidak ketika kami benar-benar menemukan kasus penggunaan di mana hal seperti ini dibutuhkan?

Karena ini adalah perubahan yang sangat besar dan sebelum 1.0 adalah saat yang tepat untuk melakukan hal tersebut. Apalagi sejak sudah berganti nama key.

Ada juga kasus penggunaan yang sangat nyata untuk itu sekarang. Paling tidak, ini memungkinkan penyimpanan kunci non-daun dengan nilai dalam format apa pun.

Untuk metadata pada kunci, spesifikasi adalah solusi yang lebih baik karena mengacu pada semua ruang nama.

Saya hanya akan menyebutkan array . Pikirkan sedikit tentang hal-hal di # 3514 dan kemudian beri tahu saya cara menyimpan array dengan benar dalam file properti Java.

Alangkah baiknya, jika metadata hanya disimpan dalam spec:/ (itu juga akan menyelesaikan beberapa masalah dengan plugin spec ), tetapi akan membutuhkan beberapa perubahan yang sangat besar pada Elektra untuk membuatnya bekerja dengan baik.

pertanyaannya adalah perilaku jika menemukan <strong i="17">@elektra</strong> = something dalam sebuah file

Jika plugin menggunakan @elektra untuk menyandikan sesuatu (misalnya nilai non-daun) maka itulah yang terjadi.
Jika tidak: "ERROR: nama kunci ilegal"

Saya akan membuat daftar di suatu tempat, sehingga kita bisa membahasnya pada hari Senin.

Seperti yang dijanjikan di https://github.com/ElektraInitiative/libelektra/issues/3223#issuecomment -709389141, sekarang saya menambahkan # 3517.

beri tahu saya cara menyimpan array dengan benar dalam file properti Java.

Ini hanya bekerja dengan spec .

tetapi akan membutuhkan beberapa perubahan besar pada Elektra untuk membuatnya bekerja dengan baik.

Apakah ada beberapa perubahan yang diperlukan yang belum ada di pelacak masalah? Saya pikir itu adalah yang harus dimiliki untuk 1.0 yang setidaknya dasar-dasar spesifikasi bekerja dengan baik (dan untuk menyingkirkan hal-hal yang tidak berfungsi).

Ini hanya bekerja dengan spec .

Tapi bagaimana caranya? Anda membutuhkan array metadata di ruang nama lain untuk mengetahui seberapa besar array sebenarnya.

Apakah ada beberapa perubahan yang diperlukan yang belum ada di pelacak masalah? Saya pikir itu adalah yang harus dimiliki untuk 1.0 yang setidaknya dasar-dasar spesifikasi bekerja dengan baik (dan untuk menyingkirkan hal-hal yang tidak berfungsi).

Tidak mungkin untuk mengatakannya. Kita perlu memutuskan spesifikasi apa yang seharusnya dilakukan. Kemudian kita perlu mencari tahu, jika dan bagaimana itu mungkin. Meskipun demikian, sangat mungkin kami menemukan beberapa kasus tepi yang tidak berfungsi. Elektra sangat rumit sehingga hampir tidak mungkin alasannya dan cakupan tes yang baik setidaknya sama sulitnya. Banyak Elektra juga masih didasarkan pada prinsip-prinsip yang ditentukan secara longgar atau tidak sama sekali.

Masalah terbesar pasti adalah posisi plugin saat ini. Tetapi itu akan membutuhkan banyak pekerjaan untuk memperbaikinya. IMO bagian itu pada dasarnya membutuhkan desain ulang yang lengkap.

Tapi bagaimana caranya? Anda memerlukan metadata array di namespace lain untuk mengetahui seberapa besar sebenarnya array tersebut.

Ya, spec benar-benar perlu memahami semantik metadata, seperti array. Jadi itu akan memeriksa semua namespace bagaimana array sebenarnya terlihat, dan kemudian menambahkan metadata yang tepat array .

Elektra sangat rumit sehingga hampir tidak mungkin alasannya dan cakupan tes yang baik setidaknya sama sulitnya.

Saya setuju, jadi buat lebih sederhana. Sekarang adalah kesempatan yang sempurna. Kami belajar banyak tentang apa yang tidak bisa dilakukan. Jadi mari kita singkirkan barang-barang itu.

Masalah terbesar pasti adalah posisi plugin saat ini. Tetapi itu akan membutuhkan banyak pekerjaan untuk memperbaikinya. IMO bagian itu pada dasarnya membutuhkan desain ulang yang lengkap.

Saya semakin setuju dengan @mpranj bahwa kaitan untuk plugin global tertentu bukanlah ide yang buruk. Persyaratan untuk plugin semacam itu cukup rumit dan dengan demikian pemosisian umum akan menjadi terlalu rumit.

Jadi kami tidak akan memiliki posisi plugin global umum tetapi hanya yang khusus untuk mmap, spesifikasi dan notifikasi (satu-satunya yang kami benar-benar butuhkan untuk 1.0). Posisi umum akan bagus, tetapi jelas di luar kemampuan kami untuk menguji ini. Saya mengubah keputusan di 89b29034e1d505f36d298f01bf0fcfd13aa1af70

Diskusi lebih lanjut silakan di # 3514