lider-ahenk-docs/developers/ahenk/ahenk_calisma_mekanigi.md

4.4 KiB
Raw Blame History

#Ahenk Çalışma Mekanikleri

###Event Tetiklemek

Ahenk pam gibi modülleri kullanarak sistem üzerindeki gerçekleştirilen kullanıcı girişi-çıkışı, sistemin kapanması vb.. aktiviteleri algılayabilir. Örneğin giriş yapan kullanıcının politikasının lider'den istenmesi için oturum açma işleminin farkedilmesi. Bu ve benzeri işlemler temelde arka planda bir terminal komutu çalıştırmaktadır. Eklenti geliştirme sırasında, benzer şekilde event tetiklemek için; ahenk çalıştığı sırada komut satırından python3 ahenkd.py [event] [parameters] şablonunda çalıştırılabilir. Örneğin python3 ahenkd.py login volkan gibi ...


###Eklenti Yapısı

Bir ahenk eklentisinin(plugin) dosya yapısı plugins dizini altında aşağıdaki gibidir:
myplugin/
      L main.py
      L policy.py
      L safe.py
      L taskId1.py
      L taskId1.py
            L api/
                  L plugin_name_Service.py
                  L environmentA1.*
                  L environmentA2
.*
                  L Default.*

  • Bu standart yapıdaki bir eklentinin taskId1 isimli görevin çalıştırılması için Ahenk çekirdeği taskId1.py daki task handle_task(task,context) fonksiyonunu tetikler. Bu fonksiyon task işleminin başlangıç noktası olarak varsayılabilir. handle_task 2 tane parametre alır. İlk parametre olan task eklenti geliştiricisinin lider bileşeninden gönderdiği json iletisidir. Görevin ihtiyaç duyduğu veriler eklentiyi tasarlayanın belirlediği yapıyla json mesajı olarak bu parametre ile değerlendirilebilir.

  • İkinci parametre olan context ahenk çekirdeği ile eklentinin ortak map i olarak düşünülebilir. context aracılığı ile görev in sonucu hakkında bilgi mesajı, veri, bu verinin tipi,... gibi içerikler döndürülebilir.

  • Politikanın işleyişi Görev ile benzerdir. Her eklentinin bir policy.py dosyası bulunur ve gelen profil datasının tamamının işlenmesinden sorumludur.


###Api Yapısı

Bazı Görev ya da Profil operasyonları sistem bileşenleri,türleri ya da versiyonları ile doğrudan ilgilidir. Bu tip bağımlılıklar genellikle bilgisayar mimarilerinden, grafik arayüz bileşenlerinden, kernel versiyonlarından kaynaklanmaktadır. Bu bağımlılık tipleri öngörülemeyecek şekilde değişebilir veya artabilir.Bu noktada hedef bilgisayarlar göz önünde bulundurularak eklenti operasyonlarının işlevselliğini sürdürebilmesi için bağımlılıklara uygun çeşitli çözümler geliştirmek eklenti geliştiricisinin sorumluluğundadır. Bu amaçla geliştiriciden beklenen yapı yukardaki dosya hiyerarşisine bağlı olarak dinamik nesne erişimi sağlayan api mekanizmasıdır. Bir örnekle açıklamak gerekirse; X eklentisinin a işlevi(ekran görüntüsü alma operasyonu gibi) makine tipi ve masaüstü platformuna bağımlılığı bulunur ve her bir ikili bağımlılık için ayrı ayrı ele alınması gerekir. Bu amaçla olası hedef makineler için a işlevini gerçekleştiren aşağıdaki gibi sınıflar oluşturulması beklenir.

  • ltsp_kde.py
  • x2go_kde.py
  • ltsp_gnome.py
  • x2go_gnome.py
  • ltsp_default.py
  • x2go_default.py
  • default_kde.py
  • default_gnome.py
  • default_gnome.py
  • default_default.py (varyasyon sayısı bağımlılık sayısına göre artıp azalabilir. Örn: x64 ve x86 mimari bağımlılığının eklenmesi) Bu sınıfları aynı interface i gerçekleyen sınıflar olarak düşünebiliriz.

Son olarak plugin_nameService.py da Ahenk çekirdeğinden alınan bağımlılık tipi bilgisine göre geçerli nesne a işlevini gerçekleştirmek üzere gerekli yerlerde kullanılır.