[Gelistirici] COMAR ve *Kit'ler

[Ozan Çağlayan]

Bahadır Kandemir wrote On 21-01-2009 13:50:
> 20 Oca 2009 Sal tarihinde, Gürer Özen şunları yazmıştı: 
>> Yani Çomar bizim jenerik *-kit'imiz olacak, import comar yerine import
>> dbus ile kullanacağız ama bize kolayca yeni yapılandırma araçları sunma
>> ve eldeki araçları Python ile daha güçlü ve maintainable şekilde
>> geliştirme imkanı verecek.
>>
>> ...
>>
>> Burada yapılacak üç iş var:
>> 1. Çomarın model yönetiminin böyle bir işe göre elden geçirilmesi.
>> 2. Sistem modelimizi elden geçirmek ve artık diğer dağıtımlarla birlikte
>> geliştirmek için gerekli ortak çalışmalara katılmak.
>> 3. Yavaş yavaş UI araçlarını bu yeni sisteme geçirmek.
>> 4. Profit!
> 
> Çomar'da DBus patikalarını (/org/freedesktop/...), çağrıyı alacak paketi 
> belirlemek için kullanıyoruz, diğer DBus servislerinde bu patikalar farklı 
> kullanılıyor. Misal, Çomar'ı NM servisini sunacak şekle sokmak için bir 
> şeyleri kırmamız gerekecek. Uygulamalar ile gelen görev betikleri 
> kavramını da bir kenara bırakmak gerekiyor, Net.Link betikleri yerine bir 
> tane NetworkManager betiği olacak.
> 
> Bunun yerine, Python-DBus ile ufak ara katmanlar yazılabilir. 
> org.freeDesktop.X metodlarını sunar, çağrı geldiğinde bunu Çomar 
> metodlarına map eder. Çomar'da değişiklik yapılmasına gerek de kalmaz. 
> Üstelik, Python-DBus ile servis oluşturma işi çok daha kolay.
> 

Sürekli yeni {ara}katmanlar giriyor devreye, katmanları arttırmak yerine ya sayısını aynı tutalım ya da azaltalım azaltabiliyorsak.

Bence Gürer'in dediği gibi front-end/GUI'lerin muhattabı doğrudan dbus olsun. Bu ne avantaj sağlar? 

1. DBUS binding'i olan herhangi bir dil ile GUI yazılabilmesini. Atıyorum ben Java ile NM yazıp,

import org.freedesktop.dbus

diyip, backend'imizi kullanabilirim.

2. import comar, comlink, gibi dışardan bakan birinin ilk bakışta ne olduğunu anlayamacağı şeyler yerine evrensel bir dbus üzerinden yola çıkılmış olur. Ben bile bir manager kodunu açtığımda comlink/comar/link/ tarzı şeyler gördüğümde 2 saat ne olduğunu, nasıl kullanıldığını, ne metodları olduğuna falan bakıyorum gidip. Oysa dbus'ın hali/tavrı belli, nasıl metod çağırıldığı belli, sadece interface/object/method bilgisi olan herkes istediği metodları çağırabilir.

Arka tarafta ise comar şu anki gibi aktivasyon altyapısını sağlayıp dbus çağrılarını karşılar. Ben Java ile yazdığım NM'de, org.hede.NetworkManager.setIPAddress() çağırdığımda comar ayağa kalkıp Net.Link bacağındaki ilgili metodu çağırır. 

Ancak bu yapıda bacaklarda da comar'a özel kod olmamalı, comar tam ortada olmalı. comar modülleri tarafından sunulan helper metodlar ayrıştırılıp ayrı bir modülde toparlanmalı. comar transparan olmalı, insanlar ortada böyle bir process'in şahlanıp işini bitirip ölmesinden haberdar olmamalı.

Diğer dağıtımlara da sunmak istiyorsak şöyle bir altyapı sunulmalı:

comar'ın hangi dbus çağrısını hangi alt çağrıya yönlendireceği belli olmalı. ancak dağıtıma özel bacaklar register edilip kullanılabilmeli. Adamların uyması gereken bir fonksiyon prototiplemesi olacak, giriş argümanları şunlar, tipleri şunlar, dönüş değeri şunlar. Böyle istediği dilde bir bacak hazırlayıp comar'ın mapping yaptığı bacağı onunla değiştirecek. Bu başka dağıtıma sunuş kısmı bence biraz daha geri planda kalmalı, ancak bunun dışındaki ayrıştırma hedeflenmeli ve frontend sadece dbus kullanmalı diyorum ben.



-- 
Ozan Çağlayan