Nunaj projektoj
Aldonaj dosierecoj [xattr]
Miaopinie, aldonaj dosierecoj (alinome: xattr-oj) mojosegas, kaj plurmaniere utilas! Mi lamentas la nunan staton de la liberaj operaciumoj (BSD, LiGNUkso, ktp) rilate al xattr-oj: Ili apenaŭ utiliĝas, kaj estas ofte traktataj kiel flanka afero nesubtenenda.
Mi uzis Hajkon [Haiku] kiel mi ĉefa operaciumo dum du jaroj, kaj ĝi malkaŝis al mi la potencon kaj belecon de aldonaj ecoj. Hajko utiligas ilin tre ofte kaj diverse; en la dosierfoliumilo, kiel datumbazo, je dosierformoj ĝenerale: Kontaktdosiero? Estas malplena dosiero, kun ecoj pridatumaj. Retpostmesaĝo? Malplena dosiero, kun ecoj pridatumaj. RSS/Atom-abono? Malplena dosiero, kun… vi jam scias.
Celo mia estas uzi aldonajn dosierecojn ĉe miaj programoj plejofte laŭutile, por proksimigi la liberajn operaciumojn al Hajko — kaj tiel, al la oso! Aldonaj ecoj utiliĝu kaj vastiĝu! :D
Tiucele, mi skribis xattr-bibliotekon por la lingvo Koka Skimo, kaj faris RSS/Atom programon kiu utiligas aldonajn ecojn, feedsnake. Sed ekde mi skribis feedsnake, mi trovis programon RSS-an kiun mi nun preferas, sfeed.
chatd
»chatd« mi nomas daŭrantan projekton, fari ĝeneralan kaj protokolneŭtralan interfacon por babilaj programoj, iom kiel Pidgin kaj similaj. Jen mia revo: Iu ajn povu skribi simplan klientprogramon kiu povas kompreni informojn laŭ »chatd«-formo, kaj tiel povus sen plia peno nerekte subteni multajn protokolojn (XMPP, IRC, Matrikson); kaj iu ajn povu skribi simplan babilan klientdemonon por tiaj protokoloj, kiuj eligus informojn »chatd«-forme.
Servilo → Klientdemono → Klientprogramo
Ideale, programaro ĉi tia ebligu: Facilan skriptadon por la uzanto; egaltraktadon de protokoloj; koherecon; simplan kaj bone apartigitan kodon; neŭtralecon je programlingvoj (kliento povus esti, ekz., Python, kaj klientdemono povus esti, ekz., Ruby). Ĝuste nun, mia alcelata strukturo estas uzi JSON por komunikado inter klientoj kaj klientdemonoj; eligo de demono estu simpla tekstdosiero, enigo de ĝi estu FIFO (speciala dosiero), simile al ii. Tiucele, mi jam ekskribis klientdemonon IRC-an irc-chatd, bibliotekon IRC-an por Koka Skimo ircc, kaj klientprogramon `ii`-stilan (kiitd).
Je ĉi tiu frua paŝo de la projekto, mi plu analizas aliajn strebojn ĉi tiajn. Mi esploras pri Teleaptio [Telepathy] ĝuste nun. Laŭ tuja rigardeto, ŝajnas bona; onidire D-Bus (kiun ĝi postulas) iom malbonas, sed ne tenas mi fortan opinion pri tio. Eble mi nuligos ĝisnunan laboron, kaj ekfevoros pri Telepatio!
Datumportado
Gravas al mi la kapablo elporti datumojn de programo kompreneblforme. Se oni, ekzemple, uzas babilprogramon, nepre facilu konserve elporti mesaĝojn al plata teksto (aŭ almenaŭ al dokumento HTML-a). Plifacilas traserĉi dosierojn rekte, kaj ofte oni ne povas fidi ke la servilo/protokolo konservos diskutojn. Je XMPP/Matrikso, okazas sufiĉe ofte ke ŝlosiloj perdiĝas, kaj tiel entute perdiĝas longaj, gravaj diskutoj. Pro ĉi tio, mi faras kelkajn skriptojn por eligi analizeble protokolojn kaj datumojn de iuj programoj kaj servoj: dino-chat-export, divercities_dl, wyrics, ktp.
Rimarkinde, estas ke la hipoteza »chatd« protokolo denature konserveblus, ĉar eligo (kaj do, babilprotokoloj) estus simple teksto. Simple JSON, facile-traktebla.
Retpoŝto
Ĉe la operaciumo Hajko, retpoŝtmesaĝo simple estas dosiero speciala, kun aldonaj dosierecoj enhavantaj la pridatumojn de la mesaĝo. Ĝia dosierfoliumilo, Spurilo [Tracker], estis farita prizorgi elstare bone tiujn aldonajn ecojn, kaj tiel montras retpoŝton tre bone. Kaj la Hajka retpoŝtmontra programo? Ĝi estas simpla sed bela.
Mi volas iom Hajkecigi la LiGNUksan retpoŝtan sperton, kaj tiucele mi prilaboris nautilus-maildir, aldonaĵo por la dosierfoliumiloj Nautilus/Caja/Nemo, kiu montras informojn pri retpoŝtmesaĝo per aldonaj eckolumnoj.