การประกาศล่าสุดที่ว่า Stalwart ได้กลายเป็นเซิร์ฟเวอร์อีเมลแรกที่นำ JMAP ไปใช้อย่างสมบูรณ์สำหรับปฏิทิน, การติดต่อ, และการจัดเก็บไฟล์ ได้จุดประกายการอภิปรายอย่างร้อนแรงในหมู่ผู้พัฒนาซอฟต์แวร์และผู้ดูแลระบบ ขณะที่หลายคนฉลองความสำเร็จก้าวสำคัญนี้ในฐานะก้าวสู่การทำให้โปรโตคอลอินเทอร์เน็ตทันสมัยขึ้น แต่บางคนก็ตั้งคำถามว่าการใช้ JSON-over-HTTP เป็นทิศทางที่ถูกต้องสำหรับมาตรฐานการสื่อสารพื้นฐานหรือไม่
คำสัญญาของระบบนิเวศโปรโตคอลแบบรวมศูนย์
การนำไปใช้ของ Stalwart นั้นแสดงถึงแพลตฟอร์มการทำงานร่วมกันด้วย JMAP ที่สมบูรณ์ที่สุดที่มีอยู่ โดยเสนอกรอบงานแบบ JSON เดียวที่เข้ามาแทนที่โปรโตคอลเดิมหลายตัว รวมถึง CalDAV, CardDAV และ WebDAV สมาชิกในชุมชนที่ใช้งาน Stalwart ในสภาพแวดล้อมการผลิตรายงานประสบการณ์เชิงบวกกับแนวทางแบบบูรณาการ ผู้ดูแลระบบรายหนึ่งซึ่งจัดการบัญชีบริษัทประมาณ 20 บัญชี ระบุว่า ความเรียบง่ายสำหรับสแต็กที่ซับซ้อนเช่นนี้และความยืดหยุ่นของการปรับใช้ นั้นสูงมาก! ความรู้สึกนี้สะท้อนถึงข้อเสนอหลักของ JMAP นั่นคือการลดความซับซ้อนในการบำรุงรักษาบริการแยกหลายๆ อย่างสำหรับจดหมาย, ปฏิทิน, รายชื่อติดต่อ และการแชร์ไฟล์
ชุมชนด้านเทคนิคดูเหมือนจะแตกออกเป็นสองฝ่ายในเรื่องที่ว่า JSON-over-HTTP แทนถึงความก้าวหน้าอย่างแท้จริงหรือไม่ นักพัฒนาบางส่วนตั้งคำถามว่าพื้นที่การออกแบบสำหรับโปรโตคอลใหม่ควรถูกจำกัดอยู่แค่ในชั้น HTTP หรือไม่ โดยเสนอแนะว่าโปรโตคอลแบบไบนารีอาจให้ประสิทธิภาพที่ดีกว่าสำหรับการดำเนินการที่ใช้ข้อมูลอย่างเข้มข้น เช่น การแชร์ไฟล์และกลุ่มซอฟต์แวร์ ส่วนผู้อื่นแย้งว่า HTTP ให้ประโยชน์ที่สำคัญ เช่น การโฮสต์เสมือน (virtual hosting) และการมาตรฐานของ URL ที่ทำให้การปรับใช้และการผสานรวมง่ายขึ้น
ฉันไม่ชอบ JSON ฉันคิดว่ามันมีปัญหาหลายอย่าง และคิดว่า DER เป็นรูปแบบที่ดีกว่า
มุมมองนี้เน้นย้ำถึงการอภิปรายที่ยังคงดำเนินอยู่เกี่ยวกับรูปแบบการจัดลำดับข้อมูล (data serialization) โดยมีนักพัฒนาบางส่วนสนับสนุนทางเลือกแบบไบนารี เช่น DER (Distinguished Encoding Rules) แทนที่แนวทางแบบข้อความของ JSON
ภาพรวมตระกูลโปรโตคอล JMAP
- JMAP for Mail: ทางเลือกสมัยใหม่ที่มาแทนที่ IMAP/SMTP
- JMAP for Calendars: ทางเลือกที่มาแทนที่ CalDAV (RFC ยังอยู่ในขั้นร่าง)
- JMAP for Contacts: ทางเลือกที่มาแทนที่ CardDAV (RFC 9610 ได้รับการรับรองเมื่อ 10 เดือนที่แล้ว)
- JMAP for File Storage: ทางเลือกที่มาแทนที่ WebDAV
- JSCalendar: วิวัฒนาการรูปแบบ JSON ของ iCalendar
- JSContact: ทายาทรูปแบบ JSON ของ vCard
การสนับสนุนจากไคลเอนต์กลายเป็นความท้าทายที่สำคัญ
แม้จะมีความสำเร็จด้านเซิร์ฟเวอร์ของ Stalwart ระบบนิเวศก็เผชิญกับความยากลำบากในการเติบโตอย่างมีนัยสำคัญ ผู้ใช้หลายรายรายงานความยากลำบากในการหาเว็บไคลเอนต์ JMAP ที่ใช้งานได้ โดยมีผู้ใช้ที่หงุดหงิดรายหนึ่งระบุว่า ฉันถามมาแล้วหลายครั้งมากนับตั้งแต่ Stalwart ถูกเปิดตัวครั้งแรก แต่ยังไม่ได้รับคำตอบที่ชัดเจน เว็บเมลไคลเอนต์ Cypht ซึ่งถูกระบุว่าสามารถใช้งานร่วมกับ JMAP ได้ รายงานว่ามีปัญหาเปิดอยู่ในการเชื่อมต่อกับอินสแตนซ์ของ Stalwart ทำให้ผู้ใช้มีตัวเลือกที่จำกัดสำหรับการเข้าถึงผ่านเว็บ
ปัญหา ไก่กับไข่ ของการยอมรับไคลเอนต์ปรากฏชัดเจน หากไม่มีสนับสนุนจากผู้ให้บริการอีเมลรายใหญ่ เช่น Gmail และ Outlook นักพัฒนาก็ตั้งคำถามถึงแรงจูงใจในการสร้างไคลเอนต์ JMAP ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุไว้ ฉันไม่เห็นข้อได้เปรียบสำหรับไคลเอนต์ในการแทนที่ WebDAV นะ... ในกรณีอื่นๆ เกือบทั้งหมดคงจะเลือกอยู่กับโปรโตคอลที่ได้รับการสนับสนุนอย่างกว้างขวางมากกว่า? ความกังวลในทางปฏิบัตินี้เน้นย้ำถึงความท้าทายที่โปรโตคอลใหม่ใดๆ ที่พยายามจะแทนที่มาตรฐานเดิมที่หยั่งรากลึกแล้วต้องเผชิญ
ไคลเอนต์ขนาดเล็กรวมถึง Mailtemi, Parula และ OpenCloud หลายตัวรายงานว่ากำลังพัฒนาการสนับสนุน JMAP ซึ่งชี้ให้เห็นว่าระบบนิเวศกำลังค่อยๆ เจริญเติบโต อย่างไรก็ตาม การขาดแคลนแอปพลิเคชันไคลเอนต์หลักสร้างอุปสรรคสำคัญต่อการยอมรับในวงกว้าง โดยเฉพาะสำหรับผู้ใช้ที่ต้องการความเข้ากันได้ข้ามแพลตฟอร์มกับแอปพลิเคชันอีเมลบนมือถือและเดสก์ท็อปที่มีอยู่
สถานะการพัฒนา JMAP Client ที่มีการรายงาน
- Mailtemi: กำลังพัฒนาการรองรับ JMAP Calendars, Contacts และ File Storage อย่างแข็งขัน
- Parula: อยู่ระหว่างการพัฒนาสำหรับโปรโตคอล JMAP
- OpenCloud: กำลังดำเนินการพัฒนา JMAP client
- Cypht: Web client ที่มีรายงานปัญหาการเชื่อมต่อกับ Stalwart
- FastMail: มีการรองรับ JMAP mail อยู่แล้ว มีแนวโน้มที่จะพัฒนาส่วน calendar/contacts ในอนาคต
อุปสรรคในการนำไปใช้และประสบการณ์การปรับใช้
ผู้ที่เริ่มใช้ในช่วงแรกรายงานประสบการณ์ที่หลากหลายกับกระบวนการปรับใช้ Stalwart ขณะที่บางคนชื่นชามแนวทางไบนารีไฟล์เดียวที่รวบรวมฟังก์ชันการทำงานซึ่งโดยปกติจะกระจายอยู่ทั่ว Postfix, Dovecot และ Rspamd แต่บางคนก็ระบุถึงช่องว่างของเอกสารประกอบที่สำคัญและความท้าทายในการกำหนดค่า ผู้ดูแลระบบหนึ่งที่กำลังย้ายจากการตั้งค่าแบบ Maddy แสดงความคิดเห็นว่า เอกสารประกอบไม่ดีเลย – ฉันว่ามันแค่พอให้ได้แนวคิดโดยรวมเท่านั้น ซึ่งเน้นย้ำถึงเส้นทางการเรียนรู้ที่เกี่ยวข้องกับระบบการกำหนดค่าของ Stalwart
ข้อกำหนดสำหรับอินเทอร์เฟซการจัดการผ่านเว็บได้พิสูจน์แล้วว่ามีปัญหาเป็นพิเศษสำหรับผู้ใช้ที่นำแนวทางโครงสร้างพื้นฐานเป็นโค้ด (infrastructure-as-code) มาปฏิบัติ ผู้ดูแลระบบหลายคนรายงานความขัดแย้งระหว่างการจัดการการกำหนดค่าแบบประกาศ (declarative configuration management) และอินเทอร์เฟซการตั้งค่าผ่านเว็บของ Stalwart โดยมีผู้ใช้หนึ่งรายระบุถึงข้อผิดพลาด 500 ที่อธิบายไม่ชัดเจนเมื่อไฟล์การกำหนดค่าถูกตั้งค่าให้เป็นแบบอ่านได้อย่างเดียว จุดเสียดสีในการนำไปใช้เหล่านี้แสดงให้เห็นถึงความตึงเครียดระหว่างอินเทอร์เฟซการจัดการที่เป็นมิตรกับผู้ใช้และเวิร์กโฟลว์การปรับใช้ที่สามารถทำซ้ำได้ได้
การจัดการเวอร์ชันก็ปรากฏเป็นความกังวลเช่นกัน โดยผู้ใช้ระบุว่าพวกเขา ทำการเปลี่ยนแปลงที่ทำให้เกิดความไม่เข้ากัน (breaking changes) กับการตั้งค่าระหว่างเวอร์ชัน ซึ่งทำให้กระบวนการอัปเกรดอัตโนมัติซับซ้อนขึ้น การขาดการสนับสนุนตัวจัดการแพ็กเกจพื้นเมือง (native package manager) บังคับให้ผู้ดูแลระบบต้องใช้สคริปต์อัปเดตที่กำหนดเอง เพิ่มภาระการบำรุงรักษาสำหรับการปรับใช้ในสภาพแวดล้อมการผลิต
ข้อควรพิจารณาในการติดตั้ง Stalwart
- ไฟล์ binary เดียวทำงานแทน: Postfix + Dovecot + Rspamd + เซิร์ฟเวอร์ปฏิทินและรายชือ
- ระบบจัดเก็บข้อมูล: ฐานข้อมูล SQL + ที่เก็บข้อมูลแบบ object storage ที่รองรับ S3
- การกำหนดค่า: ไฟล์ TOML + อินเทอร์เฟซการจัดการผ่านเว็บ
- การยืนยันตัวตน: มีระบบจัดการใบรับรอง Let's Encrypt ในตัว
- ฟีเจอร์สำหรับองค์กร: การกรองสแปมด้วย AI (เป็นตัวเลือกเสริม)
การอภิปรายภาพรวมของภูมิทัศน์โปรโตคอล
นอกเหนือจากรายละเอียดการนำไปใช้เฉพาะ การเปิดตัว Stalwart ได้จุดประกายการสนทนาที่กว้างขึ้นเกี่ยวกับวิวัฒนาการของโปรโตคอลอินเทอร์เน็ต นักพัฒนาบางส่วนตั้งคำถามว่า HTTP ได้กลายเป็นค่าเริ่มต้นสำหรับเกือบทุกสิ่งในตอนนี้ซึ่งจำกัดพื้นที่การออกแบบโปรโตคอลหรือไม่ ส่วนผู้อื่นปกป้องแนวทางนี้ โดยชี้ให้เห็นว่า HTTP ในฐานะ telnet ใหม่ มีการปรับปรุงหลายอย่างเมื่อพูดถึงข้อมูลไบนารี, การไหลของข้อมูลแบบขอ/ตอบ
บริบททางประวัติศาสตร์ของโปรโตคอลอีเมลให้ข้อมูลกับการอภิปรายในปัจจุบัน ดังที่ผู้แสดงความคิดเห็นหนึ่งระบุว่า ลักษณะที่เป็นข้อความของโปรโตคอล IETF รุ่นเก่าจำนวนมาก รวมถึงการจบบรรทัดด้วย CR LF น่าจะสามารถสืบย้อนไปถึงว่ามันง่ายแค่ไหนที่จะสร้างการนำไปใช้ที่แย่เต็มไปด้วยปัญหาย่อยๆ ที่สามารถดีบักได้โดยให้นักศึกษาปริญญาตรีนั่งอยู่ที่เทเลไทป์ มุมมองนี้ชี้ให้เห็นว่าแนวทาง JSON-over-HTTP ของ JMAP ยังคงสืบทอดประเพณีของการให้ความสำคัญกับความสามารถในการดีบักและความเรียบง่ายในการนำไปใช้เหนือประสิทธิภาพดิบ
การอภิปรายขยายไปถึงตัวเลือกรูปแบบข้อมูล โดยมีนักพัฒนาบางส่วนสนับสนุนรูปแบบการจัดลำดับข้อมูลแบบไบนารีซึ่งพวกเขาเชื่อว่าจะให้ประสิทธิภาพและความปลอดภัยของชนิดข้อมูล (type safety) ที่ดีกว่า อย่างไรก็ตาม ผู้สนับสนุนโต้แย้งว่า JSON อาจดูไม่มีประสิทธิภาพ แต่มันบีบอัดได้ดีมากและสามารถมีประสิทธิภาพค่อนข้างสูงในสตรีม gzip และ Brotli โดยเน้นย้ำถึงประโยชน์ในทางปฏิบัติของรูปแบบแบบข้อความสำหรับแอปพลิเคชันที่เน้นเว็บ
มองไปสู่อนาคต
ขณะที่ Stalwart ใกล้ถึงการเปิดตัวเวอร์ชัน 1.0.0 โครงการนี้แสดงถึงทั้งความสำเร็จด้านเทคนิคและกรณีทดสอบสำหรับการยอมรับโปรโตคอลสมัยใหม่ ปฏิกิริยาที่หลากหลายของชุมชนสะท้อนถึงการทรงตัวที่ซับซ้อนระหว่างความสง่างามทางเทคนิค, การพัฒนาของระบบนิเวศ และความกังวลในทางปฏิบัติเกี่ยวกับการปรับใช้ แม้วิสัยทัศน์ของตระกูลโปรโตคอลแบบ JSON ที่รวมเป็นหนึ่งเดียวจะน่าดึงดูด แต่การยอมรับในโลกแห่งความเป็นจริงจะขึ้นอยู่กับการแก้ไขช่องว่างการสนับสนุนไคลเอนต์, การปรับปรุงเครื่องมือสำหรับการปรับใช้ และการโน้มน้าวทั้งนักพัฒนาและผู้ใช้ว่าผลประโยชน์มีมากกว่าต้นทุนของการย้ายจากระบบเดิมที่ผ่านการทดสอบมาอย่างดีแล้ว
การพัฒนามาตรฐาน JMAP ที่ยังคงดำเนินอยู่—โดยที่ปฏิทินยังอยู่ในสถานะร่างและรายชื่อติดต่อเพิ่งได้รับการรับรองไม่นาน—ชี้ให้เห็นว่าระบบนิเวศยังคงอยู่ในสถานะไม่แน่นอน สำหรับตอนนี้ Stalwart ยืนหยัดในฐานะทั้งผู้บุกเบิกและสนามทดสอบ โดยให้ภาพ glimps ของสิ่งที่โปรโตคอลกลุ่มซอฟต์แวร์สมัยใหม่อาจกลายเป็น ในขณะเดียวกันก็เน้นย้ำถึงความท้าทายที่สำคัญที่เกี่ยวข้องกับการแทนที่มาตรฐานอินเทอร์เน็ตที่มีประวัติการนำไปใช้ยาวนานหลายทศวรรษ
อ้างอิง: JMAP for Calendars, Contacts and Files now in Stalwart