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

[Gökmen GÖKSEL]

On Tuesday 20 January 2009 18:12:27 Gürer Özen wrote:
> 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 :)
Bunda hemfikirim zaten.

> 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ı.
Bende bunu diyorum, UI ile low-level (ki şu anda COMAR temsil ediyor burayı) 
arasında bir katmanımız olsun diyorum, bizde katman kendi icinde comar'ı 
kullanır, atıyorum x dağıtımda bütün işleri kendi içinde yapar..

> 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.
Yani araya katman eklemek yerine bu katmanları COMAR'a ekleyelim mi diyorsun ? 
Eğer anladığım doğruysa bu da işimizi görmez ki.. Manager dediğin yine comarı 
import edecek, package-kit'i değil.

> 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.
Bende "arabirim" 'den kasıt olarak "interface" ten bahsediyordum zaten, evet 
bunu iyi planlamak lazım..

> 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.
+1 eğer bahsi geçen interfacelerimiz aynıysa :)

> 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.
Valla anlattıkların da düşündüklerimiz de çok güzel, yapmak lazım bunları neşe 
içinde :-)

-- 
Gökmen GÖKSEL