Nunaj projektoj
Aldonaj dosierecoj [xattr]

Miaopinie, aldonaj dosierecoj (alinome: xattr-oj) mojosegas, kaj plurmaniere utilas! Mi lamentas la nunan staton de la ĝenerala Uniksa (BSD-a kaj LiGNUksa) programaro 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 pli-mapli du jaroj, kaj ĝi montris al mi la potencon kaj belecon de aldonaj ecoj. Kontaktdosiero? Estas malplena dosiero, kun ecoj pridatumaj. Retpostmesaĝo? Malplena dosiero, kun ecoj pridatumaj. RSS/Atom-abono? Malplena dosiero, kun… vi jam scias. Tiom da aferoj utiligis aldonajn ecojn! Por la uzanto, estis du ĉefaj interfacoj, per kiu oni utiligis ilin: Unue, estas la dosierfoliumilo, Spurilo [Tracker], kiu kapablas montri ajnan aldonan econ legeble kaj redakteble al la uzanto. Due, estas per serĉmendoj. La Hajka dosiersistemo subtenas flekseblan serĉmendan lingvon, per kiu oni povas serĉi dosierojn per ajna kombino de ecoj aŭ ecvaloroj.
Celo mia estas iom Hajkecigi LiGNUkson tiusence, laŭ mia kapablo! 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.
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 prilaboras du projektojn: nautilus-maildir kaj Mailduck. Mailduck estas simpla montrilo QT-a de retpoŝto, sed estas nun nefinita — mesaĝoj kun pluraj enhavoj ne estas bone subtenataj. Kaj nautilus-maildir estas aldonaĵo al la dosierfoliumiloj Nautilus/Caja/Nemo, kiu montras informojn pri retpoŝtmesaĝo per aldonaj eckolumnoj.