[Gelistirici] Gparted'in Kdebase bağımlılığı var =)

[Gürer Özen]

On Tuesday 20 January 2009 17:23:43 Erkan Tekman wrote:

> Eğer doğru anladıysam sorun işi ÇOMAR yerine doğrudan bir yol (örneğin bir
> dosyayı değiştirme) yolu ile yapmaktan çok genelde *-manager ailesini
> Pardus'a özgü olmaktan çıkaracak şekilde tasarım değişikliği yapmak.

Bu başka bir tartışma, ama madem konu açıldı aşağıda bir öneride bulunacağım.

Ama önce ana thread'e cevap olarak, runCommand yada writeToFile metoduyla 
yapılan bir çözümü hiç bir dağıtım hiç bir şekilde kullanmayacaktır ondan 
emin olun :)

> sağlamak olacak. Temel yükü ise gerekecek ek bir katman ile performans
> düşüşü ve hata noktaları sayısının artması gibi görünüyor. Daha karmaşık
> bir sistem olacağından tasarım ve gerçeklemesinin daha uzun süreceği de bir
> olasılık.

Yeni bir katman, büyük iş gücü vb niye gereksin?

Şimdi elimizdeki Çomar dbus üzerinden çalışıyor, herkesin kullandığı policykit 
ile entegre, göreli olarak çok az bağımlılığı var. Başka bir dağıtımda 
çalıştırmak için ufak bir binary'yi ve ilgili python betiklerini kurmak 
yeterli.

Diğer dağıtımlarda kullanılan sistemlerden benim gördüğüm tek farkımız şu: 
Ayrı ayrı package-kit, disk-kit, hede-kit gibi çözümler yerine tek ve ufak 
bir Çomar C arayüzü arkasında işleri yapan Python betiklerimiz var.

Önereceğim strateji şu:

1. Yapılandırma betiklerini Python ile yazmak çok robust, kolay ve 
maintainable bir çözüm, bunu koruyalım. O şikayet ettiğiniz network 
betiklerini C ile yazsaydık ne halde olacaklarını bir düşünün, yada 
düşünmeyin NetworkManager koduna bir bakın :)

2. Managerları UI olmaktan çıkarmakla başka yerlerde kullanılmasını 
sağlayamazsınız. UI istemcileri ile asıl low-level sistem yapılandırma 
kısımları mutlaka ayrı olmalı.

3. Sorun üstte yada altta değil ortada. Şu anda Çomar, UI ile betikler 
arasında bir mapping yapıyor. Bunu genişletelim. Mesela Çomar Package-kit 
arayüzünü de sunsun aynı metotlarla, ama arkada bizim Python betikleri 
işlesin. Böylece package-kit'e bişiler eklemeye uğraşmadan, onun için 
yazılmış arayüzleri import pisi; pisi.install(name) şeklinde betiklerimizle 
kullanabilelim. Bizim package-manager'ımız da diğer dağıtımlardaki 
package-kit altyapısı ile çalışsın rahatça.

Henüz standartlaşmamış şeyler için oturup modeller oluşturalım. Burada önemli 
olan "interface", onun altta nasıl implemente edildiği değil. Interface ise 
iyi düşünülür ve hızlı prototiplenirse çok kolay diğer dağıtımlara 
satılabilecek bir şey. Şu anda standartlaşmış olanları da elimizdeki 
araçlarla orjinalinden çok daha kolay sunabiliriz.

Bu maddeyi gerçekleştirebilmek için fazla bir emeğe ihtiyaç yok. Çomar'ın 
model sistemini bir elden geçirmek, daha sonra da standartlaşan konularda 
(network, hal, vb) ortak modeller kullanmaya yönelmek yeterli.

Bu stratejiden en önemli kazancımız, bir yandan diğer dağıtımlarla 
interoperability'yi arttırırken, diğer yandan kendi Python ile geliştirme 
avantajımızı koruyarak kullanıcılara daha hızlı ve kaliteli çözüm 
ulaştırabilmek.