כשמהנדסים רוצים לבצע שינוי במנוע העיבוד של Blink, הם מפרסמים הודעה ברשימת התפוצה blink-dev כדי לקבל אישור להמשך. הפוסטים האלה ברשימת התפוצה נקראים Blink Intents.
דפדפני אינטרנט שמבוססים על Chromium משתמשים במנוע העיבוד Blink כדי להפוך קוד ומשאבים לדפי אינטרנט שאפשר לצפות בהם ולקיים איתם אינטראקציה.
במאמר הזה נסביר איך עובדים ממשקי ה-Intent של Blink, למה הם חשובים ואיך תכונות חדשות מתווספות ל-Blink.
Chromium ו-Blink
Chromium הוא פרויקט דפדפן בקוד פתוח שעליו מבוססים Chrome וחלק מהדפדפנים ומסגרות העבודה האחרים. Blink הוא מנוע העיבוד שמשמש את Chromium.
כדי שתכונה חדשה תופיע ב-Blink, היא צריכה לעבור את תהליך הפיתוח הפתוח של פרויקט Chromium. "תכונה חדשה" היא כל שינוי או תוספת לקוד או לארכיטקטורה של הדפדפן. יכול להיות שזה יהיה ממשק API חדש של JavaScript, שיפור משמעותי בביצועים של קוד Blink או שינוי אחר במראה או בפונקציונליות של הדפדפן.
תהליך פתוח ושיתופי
Chromium הוא פרויקט גדול ומורכב עם אלפי תורמים. כשמתבצעים שינויים ב-Chromium, כל אבן דרך היא הזדמנות להזמין את קהילת האינטרנט הרחבה להגיב על העיצוב וההטמעה.
בכל מקום שאפשר, תכונות חדשות צריכות להיות ניתנות להפעלה הדדית בפלטפורמת האינטרנט, ולא להיות מיושמות רק בדפדפן אחד. מפתחי אתרים לא אוהבים הפתעות: כשדפדפנים לא פועלים כמו שציפיתם – או כשאתם צריכים לכתוב קוד שונה לדפדפנים ולפלטפורמות שונים. ה-Intents של Blink עוזרים לבנות את תהליך השינוי ולפקח עליו, כדי שהשינויים יהיו צפויים יותר ולא יפתיעו את מפתחי האתרים.
מבחינת המשתמשים, ספקי הדפדפנים צריכים לוודא שהשינויים לא יגרמו לאתרים להפסיק לפעול. בעלי אתרים מפסיקים לעיתים קרובות לתחזק אתרים. חלק מהאתרים לא עודכנו כבר עשרות שנים! ספקי דפדפנים צריכים לקחת את זה בחשבון כשהם מבצעים שינויים שעלולים לגרום לבעיות.
מהרעיון להצעה
הצעות לשינויים ולעדכונים בפלטפורמת האינטרנט מגיעות ממחקר: התייעצות עם משתמשים, עסקים, מהנדסי דפדפנים, מפתחי אתרים ובעלי עניין אחרים. המחקר הזה מאפשר לצוות Chrome להבין מה חסר בפלטפורמה או מה צריך לשנות. בתחילה, הצעה לשינוי או לתכונה חדשה בפלטפורמת האינטרנט היא רק מילים בדף. מהנדסים משתפים מסמכים כדי לקבל משוב ולנהל דיונים עם עמיתים.
דוגמה: FedCM
Federated Credential Management (FedCM) הוא ממשק API שמציע גישה ידידותית למשתמשים ומתמקדת בשמירה על הפרטיות בתהליך ההרשמה וההתחברות של משתמשים, שנקראת זהות מאוחדת. לדוגמה, זה חל על כניסה באמצעות חשבון Google ועל כניסות אחרות דרך רשתות חברתיות.
כדי ליצור API לדפדפן, השלב הראשון הוא להכין הצעה לדיון ציבורי. ההצעה של FedCM פורסמה ב-GitHub כהסבר. כולם מוזמנים לשאול שאלות או להגיב על עיצוב התכונות, על ידי יצירת בעיה ב-GitHub במאגר ההסברים. המשוב יכול לכלול תיאורים של תרחישי שימוש נוספים, אילוצים, רעיונות לשיפור או הבטחה לתמיכה.
אחרי שגוף תקנים, כמו W3C, מאמץ הצעה, בעלי עניין יכולים להצטרף לדיונים ולצפות במצגות בקבוצות של תקני אינטרנט, כמו W3C Working Groups.
Blink Intents: Milestones and progress
בכל אבן דרך שמהנדסים עובדים על תכונה חדשה או על שינוי במנוע העיבוד של Blink, הם מפרסמים פוסט בקבוצת הדיון blink-dev, ומסבירים שהם מתכוונים לעבור לשלב הבא לקראת הטמעה של תכונה. הפוסטים האלה נקראים 'כוונות'. כל אחד יכול להירשם לקבוצת blink-dev כדי לקבל עדכונים על התקדמות בפיתוח תכונות חדשות ב-Blink, או להירשם לקבלת עדכונים על תכונה ספציפית.
כוונה ליצור אב טיפוס
בשלב הזה, מהנדסי Chromium יכולים להתחיל להטמיע תכונה. המשמעות היא שאולי תהיה זמינה פונקציונליות של אב-טיפוס של התכונה לבדיקות של מפתחים מאחורי דגל תכונה, תחילה ב-Chrome Canary ואחר כך בערוצי הפצה אחרים. כל משתמש יכול להגדיר תכונה ניסיונית בדף chrome://flags כדי להפעיל ולבדוק אותה בדפדפן שלו.
עם זאת, אי אפשר להגדיר את כל הדגלים מהדף chrome://flags. כדי לקבל שליטה מדויקת יותר, אפשר להריץ את Chrome ממסוף באמצעות פקודות של שורת הפקודה. חשוב לזכור שחלק מהתכונות החדשות לא זמינות עד שהתכונה מופצת לבדיקה ב-Chrome Canary – אבל זה קורה לעיתים רחוקות. לחלק מהתכונות אין דגל משלהן, אבל הן זמינות אם הדגל experimental-web-platform-features מופעל. זה בדרך כלל המצב לגבי תכונות 'קטנות' יותר, שנדרשים לכל היותר שלושה עד שישה חודשים להטמעה שלהן.
איסוף משוב על אבות טיפוס
אחרי שמתחילים ליצור אב טיפוס של תכונה חדשה, מהנדסי Chromium מזמינים דיון וניסוי מוקדם. המשוב בשלב הזה הוא קריטי כדי לאמת את ההצעות ולשפר אותן. Chromium bugs הוא המקום להוסיף הערות על ההטמעה ב-Chrome.
כוונה להתנסות: בדיקות בעולם האמיתי
אם מהנדסי Chrome רוצים לבקש להפעיל גרסת מקור לניסיון, השלב הבא הוא לפרסם ב-blink-dev הודעה על כוונה לבצע ניסוי.
גרסאות מקור לניסיון הן דרך לבדוק תכונה חדשה או ניסיונית של פלטפורמת אינטרנט. נרשמים לגרסת מקור לניסיון של תכונה, ואז מקבלים טוקן לניסיון. התכונה תופעל בכל דף שבו מסופק הטוקן.
אישור מבעלי Blink API
כדי שההטמעה של תכונה תתקדם, הבעלים של Blink API צריכים לאשר אותה. הם עושים זאת באמצעות תגובה לכוונת ההטמעה בפוסט עם הכיתוב "נראה לי טוב" (LGTM).
הבעלים של Blink API הם קבוצה קטנה של תורמים ל-Chromium, בעלי ניסיון רב בפלטפורמת האינטרנט ובממשקי ה-API שלה. קהילת Blink הסכימה שהם עומדים בדרישות, ומחויבים למשימה ולערכים של Blink. בנוסף לאישור (או אי-אישור) של תכונות להמשך הפיתוח, בעלי ה-API מפקחים על תהליך הכוונה של Blink עצמו.
כדי להמשיך בניסוי, צריך לקבל לפחות אישור אחד מבעלי ה-API.
הערך של גרסאות מקור לניסיון
מפתחים יכולים להירשם לגרסת מקור לניסיון של תכונה, ואז לבדוק את התכונה בסביבות ייצור בעולם האמיתי, עם משתמשים אמיתיים – בלי שהמשתמשים יצטרכו לבצע פעולה כדי להפעיל את התכונה. המפתחים יכולים לשתף את התוצאות של הבדיקות שלהם, וכך לספק תובנות ונתונים חשובים שיעזרו להם לבצע איטרציה ולפתח את התכונה.
הכוונה לשלוח: אבן הדרך האחרונה
האותות של 'כוונה להשיק' מציינים שתכונה הושלמה ועכשיו היא מוכנה להטמעה לזמינות לכלל המשתמשים (GA), לכל המשתמשים בגרסה יציבה של Chrome בלי צורך בדגל או באסימון ניסיון. כדי להמשיך בהטמעה, צריך לקבל שלושה אישורים (LGTM) מבעלי API.
השקה של תכונות חדשות
אחרי האישור, התכונה משולבת בגרסה הקרובה ואז עוברת דרך ערוצי ההפצה של Chrome. בדיקה והטמעה של תכונות חדשות מתבצעות בדרך כלל בזהירות רבה. חלק מהתכונות מושקות בהדרגה, למספר הולך וגדל של משתמשים. יכול להיות שנחזיר תכונות למצב הקודם ונשפר אותן אם יהיו להן תופעות לוואי לא צפויות.
ניהול הוצאה משימוש והסרה
יש עוד שני סוגים של כוונות ב-Blink:
- הודעה על הוצאה משימוש
- כוונה להסיר
אולי זה נשמע קצת עצוב, אבל הם למעשה קריטיים להצלחת הפיתוח של Blink.
מהנדסים מפרסמים הודעה על כוונה להוציא משימוש כשהם רוצים להתחיל להזהיר מפתחים שתכונה מסוימת עומדת לצאת משימוש. לדוגמה, על ידי מתן תמיכה ומידע על הוצאה משימוש במסוף של כלי הפיתוח ל-Chrome.
הודעה על כוונה להסרה מתפרסמת כשהמהנדסים מתכוונים להשבית קוד כברירת מחדל.
החשיבות של הוצאה משימוש והסרה
הוצאה משימוש והסרה הן פעולות קריטיות לשמירה על תקינות פלטפורמת האינטרנט. הם מוודאים ש-Chrome יכול להסיר תכונות שלא פועלות טוב בשביל משתמשי הקצה או מפתחי האינטרנט, ועוזרים לצמצם את המורכבות של בסיס הקוד. לדוגמה, בעיות בעיצוב של AppCache התגלו אחרי שהשתמשו בו באתרים פעילים בדפדפנים יציבים, ובסופו של דבר ממשק ה-API הוסר. הוצאה משימוש והסרה של תכונות עוזרות גם לשמור על Chrome בטוח ומאובטח, על ידי צמצום וקטורי התקפה פוטנציאליים.
כמו בכל הכוונות של Blink, צוות Chrome עושה כמיטב יכולתו לגשת להחלטות בזהירות. הם בודקים את שיעורי השימוש בתכונות ונתונים אחרים לפני שהם ממשיכים. הסף להסרת תכונות הוא גבוה מאוד, ותכונה תוסר רק אם מספר קטן מאוד של משתמשים משתמשים בה, ואם יש חלופות טובות יותר.
איך להתעדכן בשינויים ב-Blink Intents
אפשר לעקוב אחרי התקדמות התכונות בסטטוס של Chrome, שם אפשר להירשם לעדכונים, לדווח על באגים ולמצוא מקורות מידע נוספים.
כדי לעקוב אחרי תכונות חדשות, כדאי לעקוב אחרי הבלוג של Chromium ולהצטרף לקבוצת הדיון blink-dev. הקבוצה יכולה להוביל להרבה אימיילים, ולכן יכול להיות שתעדיפו להירשם לכוונת חיפוש אחת. אפשר לראות גיליון אלקטרוני של כוונות Blink.
אם מאוד אהבתם את Blink Intents, אתם יכולים אפילו להשתמש בשירותים האוטומטיים של Blink Intent Tracker.