[Gelistirici] 2011/devel/system/base/pciutils - Version bump, refactor package, update PCI ID data...

[Gürer Özen]

11 Haziran 2010 Cuma günü (saat 14:12:50) Gökmen Görgen şunları yazmıştı:

> Bir şey soracağım: Neden pspec, translations dosyalarımız XML formatında?

Validate etmesi ve çeşitli araçlarla işlemesi kolay diye. Okunaklılık, 
genişletilebilirlik, standartlık, otomatize edilebilirlik gibi kriterlere göre 
düşünülmüştü. Pisi dökümanında baya anlatılmış olması lazım nedenlerin.

Translations ve geri kalan bilgiler farklı kişiler (packager ve translators) 
tarafından ve farklı araçlarca update edildiği için ayrılmıştı.

> Zamanında neden bu dosyaların XML olması gerektiğine karar verildiğini
> hatırlayan bir arkadaş varsa merakımı giderebilir mi? Hem json'a göre daha
> okunaklı, hem XML'i json kadar hızlı parse edebilecek piksemel uygulamamız
> olduğu için mi XML tercih edildi?

Epey süre Python'ın kendi parser'ını kullandık, bir o kadar da 4suite parser 
ile devam ettik. Ciddi hız farkı olmasa piksemele geçmezdik tahminen.

> 2011 için böyle köklü bir değişikliğin yapılması söz konusu olabilir mi
> bilmiyorum (pisi kodu karışık :P) ama şuradaki gibi bir pspec dosyası
> düşünmemiz mümkün mü (md5sum satırına kadar kısma bakınız, gerisi için
> actions.py hallediyor):
> http://repos.archlinux.org/wsvn/packages/xz/trunk/PKGBUILD

Zaman içinde yeni ihtiyaçlar eklenmesine oldukça iyi dayandı pspec.xml formatı 
diye düşünüyorum.

Örnek verdiğin dosya basit görünüyor ama bu çok aldatıcı. Aslında epey bir 
sentaks var orada ve yeni şeyler eklemek gerektiğinde bu sentaksı sürekli 
genişletmek gerekecek.

> xml'den bash dosyasına geçelim de demiyorum ama .txt bile olabilirdi.
> Tamam, bir .txt dosyası parse etmek daha fazla zaman alır ama paketin
> içinde yine xml şeklinde durabilir bu bilgiler.

Asıl sorun .txt işleyen araçları yazmanın daha karışık olmasında. Çünkü her 
seferinde hazır araçları kullanmak yerine oradaki kafamıza göre koyduğumuz ve 
başka yerde kullanılmayan sentaksı işleyecek kodlar yazmak gerekecek yada 
oldukça kırılgan regexpler ile işleyeceğiz.

JSON gibi yaygın bir format olabilir belki, ama bir sürü aracı değiştirmek 
gerekecek ve gerçek bir getirisi var mı diye düşünmek lazım.