- Açık kaynak işbirliği sunucusu Stalwart, 4 yıllık geliştirme sürecinin ardından takvim, kişiler, dosya depolama ve paylaşım için JMAP'i tam olarak hayata geçirerek yeni bir kilometre taşına ulaştı
- Bu sürümle birlikte Stalwart, JMAP protokol ailesinin tamamını tam olarak destekleyen ilk sunucu oldu ve e-postanın ötesine geçerek işbirliğinin geneline yayılan birleşik bir API sundu
- JSON tabanlı tek bir çerçeve ile mevcut WebDAV, CalDAV ve CardDAV'ın karmaşıklığını ve verimsizliğini yerine daha geliştirici dostu bir yapı getiriyor
- Yeni JSCalendar ve JSContact formatları, iCalendar ve vCard'ın karmaşıklığını ortadan kaldırarak net ve tutarlı veri modelleri sunuyor
- Bu gelişme, açık standartlara dayalı işbirliği teknolojilerinin evrimini simgeliyor ve gelecekte takvimleme, dosya paylaşımı ve posta entegrasyonu ekosisteminde yeniliğin hızlanacağına işaret ediyor
Yeni nesil protokoller
- Son birkaç yıldır IETF, e-posta, takvim ve kişilerin senkronizasyonu ile paylaşım yöntemlerini yeniden tanımlıyor
- Mevcut JMAP for Mail'in başarısı üzerine, takvimler, kişiler, dosyalar ve paylaşım için genişletilmiş protokoller de kullanıma sunuldu
- JMAP for Calendars - CalDAV ve CalDAV Scheduling için modern bir alternatif
- JMAP for Contacts – CardDAV için güçlü bir alternatif
- JMAP for File Storage – WebDAV tabanlı dosya depolamayı ikame ediyor
- JMAP Sharing – WebDAV ACL'nin modern halefi
- JSCalendar - JSON tabanında daha temiz bir yapıyla evrilen iCalendar
- JSContact – vCard'ın modernleştirilmiş JSON tabanlı halefi
- Bu standartlar, parçalı WebDAV tabanlı teknolojilerin yerine birleşik ve zarif bir ekosistem sunuyor
- On yıllardır süren uyumluluk sorunlarını çözüyor ve tek bir veri modeliyle işbirliği özelliklerini sadeleştiriyor
Mevcut teknolojilerin sınırları
- WebDAV, CalDAV ve CardDAV uzun süre istikrarlı biçimde kullanıldı, ancak XML tabanlı tasarımları nedeniyle aşırı ayrıntılı ve tutarsız kaldılar
- Veriler HTTP başlıkları, XML yükleri ve iCalendar verileri gibi farklı noktalara dağılmış olduğundan, istemci ve sunucu arasında birlikte çalışabilirlik sorunları sıkça ortaya çıkıyor
- iCalendar ve vCard da onlarca yıllık teknik borcu taşıyor
- Az kullanılan ya da artık terk edilmiş çok sayıda özellik var ve sürümler arasındaki uygulama farkları nedeniyle karmaşık ayrıştırma mantığı gerekiyor
- Bu yapısal karmaşıklık, bakım ve ölçeklenebilirliği zorlaştırıyor ve modern işbirliği ortamları için uygun olmaktan çıkıyor
Modern gereksinimlere uygun JMAP'in yükselişi
- JMAP protokolü, başlangıçta IMAP ve SMTP'nin yerine geçmek üzere geliştirilen verimli ve sade bir posta iletişim protokolüydü
- HTTPS üzerinden JSON temeli sayesinde hem açıklık hem de ağ verimliliği sağlıyor
- Artık JMAP for Calendars, Contacts, Files ve Sharing ile aynı tasarım felsefesi işbirliğinin tamamına yayılıyor
- Posta, takvim, kişiler, dosyalar ve paylaşılan kaynaklar için birleşik ve tutarlı bir API sunuyor
- JSCalendar ve JSContact, mevcut iCalendar ve vCard'ı JSON tabanlı formatlar olarak yeniden kurguluyor
- Gereksiz özellikleri kaldırıyor, net ve tutarlı veri modelleri sunuyor
- İnsan tarafından okunması kolay, geliştirici dostu ve ayrıştırma açısından verimli oldukları için modern uygulamalar için optimize edilmişler
- JMAP ile bu yeni veri modellerinin birleşimi, takvimleme, kişi yönetimi ve dosya paylaşımının daha hızlı ve daha güvenilir biçimde uygulanmasını mümkün kılıyor
Bu sürümün anlamı
- Bu sürüm, yalnızca yeni özellikler eklenmesinin ötesinde, grup yazılımı protokol tasarımında bir dönüm noktasını temsil ediyor
- Geliştiriciler ve kurumlar, posta, kişiler, takvim ve paylaşılan kaynakları tek bir JSON tabanlı çerçeve üzerinde inşa edebilecek
- JMAP'in sadeliği ve öngörülebilirliği, istemci ve sunucuların protokol işleme yerine işlevlere ve kullanıcı deneyimine odaklanmasını sağlıyor
- Sonuç olarak birlikte çalışabilirlik sorunlarının azalması, geliştirme hızının artması ve yeniliğin hızlanması bekleniyor
- Bu da işbirliği yazılımlarının genelinde standartlaşma ve verimlilik artışını teşvik edecek bir adım
İstemci desteği ve ekosistemin genişlemesi
- Stalwart şu anda JMAP protokol ailesinin tamamını tam olarak destekleyen ilk sunucu olsa da, istemci desteği henüz erken aşamada
- Ancak şimdiden birçok proje yeni standartları benimsiyor
- Mailtemi, Parula, OpenCloud ve diğerleri, JMAP Calendars, Contacts ve File Storage istemcileri geliştiriyor
- Ekosistem hızla büyüyor ve geliştiriciler JMAP'in zarafetini ve gücünü doğrudan deneyimledikçe hızlı bir yayılım bekleniyor
2 yorum
Güzel!!
Hacker News yorumu
JMAP'in e-posta istemcisi geliştirmek için çok iyi bir protokol olduğunu düşünüyorum
Kendi kendime barındırmaktan kaçınmak isterim ama Stalwart'ı istemcinin sunucu bileşeni olarak kullanıp mevcut IMAP verisini senkronize etmek ve ona JMAP API üzerinden erişmek mümkünse ilginç olurdu
IMAP-IMAP senkronizasyonu gibi bir şeyin mümkün olduğunu duydum; bunu Stalwart ile deneyen biri var mı merak ediyorum
Böyle bir yaklaşım mümkün olursa mevcut IMAP posta kutularına JMAP ile erişilebilir hale gelir ve yeni nesil e-posta istemcilerinin geliştirilmesini hızlandırabilir
Stalwart gerçekten çok güzel yapılandırılmış bir yazılım
Güven oluşturarak zaman içinde olgunluğunu kademeli biçimde artırmış olması etkileyici
Üstelik bunun neredeyse tek bir geliştirici tarafından sürüklenmiş olması şaşırtıcı
GitHub katkıcı grafiği
Uzak IMAP'i düzenli olarak Stalwart'ın yerel IMAP sunucusuna senkronize ederseniz, Stalwart bunu içeride JMAP'e dönüştürüp sunar
Başta bunun için maildir aşaması gerekir sanmıştım ama yalnızca IMAP ↔ IMAP ile de gayet mümkün görünüyor
Şimdiye kadar bulduklarım fazla pahalıydı, o yüzden bu gelişme sevindirici
Henüz ortaya çıkmış bir şey yok ama aklımda tutuyorum
Stalwart fiilen JMAP'in ilk sunucu uygulaması olduğuna göre artık istemci yapmak için de bir neden var
Bu arada Mozilla'nın yeni posta hizmeti de JMAP kullanmayı planlıyor, bu da büyük bir ivme sağlayabilir
Eskiden Nextcloud ya da SoGo gibi groupware çözümlerini denedim ama hayal kırıklığı yarattılar
Ama şimdi Nextcloud'un Stalwart ile iş birliği yapması ve Opencloud ile Mozilla/Thunderbird tarafında da JMAP entegrasyonunun sürmesi umut veriyor
Özellikle Thunderbird'ün webmail projesi Stormbox da ilerliyor, bu da ilginç
Şu anda Big Tech'ten uzaklaşma eğilimi güçlendiği için zamanlaması da kusursuz
Cyrus yalnızca JMAP mail desteği sunuyordu
Artık CalDAV, JMAP ve dosya sistemi arasında senkronizasyon mümkün
Ben aerc adlı istemciyi kullanıyorum
Dosya paylaşımı, groupware, posta ve takvim gibi şeyler JSON ek yükü olmadan daha verimli tasarlanabilir gibi geliyor
Yine de HTTP tabanlı tasarımın mutlaka bir nedeni vardır
İlk internet protokollerinin çoğu metin tabanlı Telnet üzerinde inşa edildiği için böyle
HTTP/3 özünde ikili bir protokol ve JSON yapısal olduğu için de sıkıştırma açısından oldukça verimli
“JSON over HTTP”, “custom text over telnet”e göre küçük ama net bir ilerleme
capnproto, grpc, ASN.1 gibi çerçeveleri kullansanız da her birinin ayrı bir karmaşıklığı var
JSON basit ve sınırları net, bu yüzden onunla çalışmak kolay
Buna karşılık Microsoft Exchange protokolleri gibi uygulamaya bağımlı tasarımlar uzun vadede sorun çıkarıyor
Bazı durumlarda TCP dışındaki başka bir protokol daha iyi olabilir
Ben şahsen JSON'dan hoşlanmıyorum; DER biçiminin daha iyi olduğunu düşünüyorum
Gemini ve Scorpion gibi “small web” protokolleri de ilginç
Hatta web istemcisi uyumluluğu açısından HTTP tek gerçek seçenek
HTTP kullanmamanın neredeyse hiçbir avantajı yok
JSON yerine CBOR kullanılırsa yük de ikili hale getirilebilir
HTTP bir durum aktarımı (state transfer) protokolüdür, bu yüzden senkronizasyon için uygundur
Buna Braid uzantısı eklenirse bir durum eşzamanlama (state synchronization) protokolüne genişletilebilir
Ben Braid projesinde çalışıyorum
Posta tarafı zaten destekleniyor ama hâlâ CardDAV/CalDAV ile birlikte kullanmak gerekiyor
10 yıl önce yazılmış
caldav_synckodu hâlâ çalışıyorYakın zamanda objectid üretim mantığı iyileştirildi; böylece ID boyutu küçüldü ve sıralanabilirlik arttı
Şimdi takvim ve kişileri güncel JMAP spesifikasyonuna yükseltmeyi planlıyorlar
Dosya sistemi tarafı biraz daha zaman alacak gibi
Taslak belgeye bakabilirsiniz
Contacts ise 10 ay önce RFC 9610 olarak onaylandı
Mevcut çözümlere kıyasla hangi sorunu çözdüğü de çok net değil
Apple Mail, Thunderbird ve Outlook gibi büyük istemcilerin desteklemesi gerekiyor
Canary veya Spark gibi daha küçük istemciler bunu farklılaştırıcı bir özellik olarak ekleyebilirdi ama şaşırtıcı biçimde yapmıyorlar
Yeni Outlook tüm veriyi Azure'da saklıyor ve gerçek sunucuyla bir proxy üzerinden konuşuyor
JMAP desteği ekleme ihtimali neredeyse yok
(Bu, IMAP'i savunduğum anlamına gelmiyor)
Gmail ya da iCloud desteklemiyorsa istemci geliştirmenin de anlamı azalıyor
Çift destek mümkün olabilir ama pazar dar
Ama bunun gerçekleşmesi için hâlâ çok fazla “if” var
Tam entegre bir sunucu olduğu için sanki yeni bir dönem açılmış gibi hissettiriyor
Maddy de fena değil ama bakım temposu daha düşük
Seçenekleri, varsayılanları ve aralarındaki ilişkileri tek bakışta görebileceğiniz bir belge yok
Web UI üzerinden yapılandırma yapılabiliyor ama bu deklaratif dağıtım ile çelişiyor
.tomldosyası salt okunursa hata veriyorFastMail ve Topicbox dışında doğru düzgün bir seçenek yok gibi
Roundcube ya da Wildduck gibi HTTPS üzerinden self-host edilebilen bir şeye ihtiyaç var
“Rust ile baştan yazıldı” dışında belirgin bir fark göremiyorum
İyi bir MUA (posta istemcisi) yokken JMAP'in ne kadar yardımcı olacağı da şüpheli
Sunucu tarafı zaten çözülmüş bir sorun ama istemci tarafı durgun
IMAP4'ün özelliklerinin çoğu bile uygulanmadı, Sieve istemcileri de çok kötü
Dovecot hâlâ UTF-8'i bile tam desteklemiyor
Stalwart gibi projeler bu tür eski miras sınırlamaları aşmaya çalışıyor
İstemci tarafında da Apple Mail gibi ilerleme gösteren örnekler oldu
Bunlardan yalnızca birinin gelişmesi yeterli değil
Artık iyi bir sunucu ortaya çıktığına göre geriye iyi istemciler kalıyor
Nylas güçlü ama pahalı
Büyük ölçekte hesap başına aylık $1.50, SaaS marjlarını etkileyebilir
Yine de gerçek zamanlı e-posta analizi veya özel UI oluşturma için çok kullanışlı