כשמהנדסים רוצים לבצע שינוי במנוע הרינדור של Blink, הם מפרסמים ברשימת התפוצה blink-dev כדי לקבל אישור להמשיך. ההודעות האלה ברשימות התפוצה נקראות Blink Intents.
דפדפני אינטרנט שמבוססים על Chromium משתמשים במנוע הרינדור Blink כדי להפוך קוד ומשאבים לדפי אינטרנט שאפשר להציג ולנהל איתם אינטראקציה.
במאמר הזה נסביר איך פועלים כוונות השימוש ב-Blink, למה הן חשובות ואיך תכונות חדשות מגיעות ל-Blink.
Chromium ו-Blink
Chromium הוא פרויקט הדפדפן בקוד פתוח שעליו מבוססים Chrome ודפדפנים ותבניות אחרות. Blink הוא מנוע הרינדור שבו משתמש Chromium.
כדי שתכונה חדשה תגיע ל-Blink, היא צריכה לעבור את תהליך הפיתוח הפתוח של פרויקט Chromium. 'תכונה חדשה' היא כל שינוי או הוספה לקוד או לארכיטקטורה של הדפדפן. יכול להיות שמדובר בממשק API חדש של JavaScript, בשיפור משמעותי בביצועים של קוד Blink או בשינוי אחר כלשהו במראה או בפונקציונליות של הדפדפן.
תהליך פתוח ושיתופי
Chromium הוא פרויקט עצום ומורכב עם אלפי שותפים. כשיש שינויים ב-Chromium, כל אבן דרך היא הזדמנות להזמין את הסביבה העסקית הרחבה יותר של האינטרנט להגיב על העיצוב וההטמעה.
במידת האפשר, התכונות החדשות צריכות להיות תואמות לפלטפורמת האינטרנט, ולא להיות מוטמעות רק בדפדפן אחד. מפתחי אתרים לא רוצים הפתעות: כשדפדפנים לא פועלים כמצופה, או כשצריך לכתוב קוד שונה לדפדפנים ולפלטפורמות שונים. כוונות Blink עוזרות למבנה ולווסת את תהליך השינוי, כדי שהשינויים יהיו צפויים יותר ולא מפתיעים, וזה טוב למפתחי אתרים.
מבחינת המשתמשים, יצרני הדפדפנים צריכים להקפיד שהשינויים לא יגרמו לאתרים להפסיק לפעול. לעתים קרובות, בעלי אתרים מפסיקים לתחזק אתרים. חלק מהאתרים לא עודכנו כבר עשרות שנים! יצרני הדפדפנים צריכים לקחת זאת בחשבון כשהם מבצעים שינויים שעשויים לגרום לשיבושים.
מהרעיון להצעה
הצעות לשינויים ועדכונים בפלטפורמת האינטרנט מגיעות ממחקר: ייעוץ עם משתמשים, עסקים, מהנדסי דפדפנים, מפתחי אינטרנט וגורמים אחרים בעלי עניין. המחקר הזה מאפשר לצוות Chrome להבין מה חסר בפלטפורמה או מה צריך לשנות. בהתחלה, הצעה לשינוי או לתכונה חדשה בפלטפורמת האינטרנט היא רק מילים בדף. מהנדסי תוכנה משתפים מסמכים כדי לקבל משוב ודיון מהעמיתים שלהם.
דוגמה: FedCM
Federated Credential Management (FedCM) הוא ממשק API שמספק מנגנונים חדשים וטובים יותר לפלטפורמות שמנהלות את ההרשמה והכניסה של המשתמשים, שנקראים זהויות מאוחדות. לדוגמה, כשאתם בוחרים באפשרות 'כניסה באמצעות חשבון Google' או 'כניסה באמצעות GitHub'.
כשהצעה כמו FedCM מוכנה לדיון ציבורי, היא מתפרסמת ב-GitHub כהסבר. בשלב הזה, כל אחד יכול ליצור פנייה במאגר ההסברים ב-GitHub כדי לשאול שאלה או להגיב על העיצוב של תכונה. המשוב יכול לכלול תיאורים של תרחישים לדוגמה או אילוצים נוספים, רעיונות לשיפורים או פשוט תמיכה.
אחרי שהצעה מסוימת מאושרת על ידי גוף סטנדרטיזציה, כמו W3C, בעלי העניין יכולים להצטרף לדיוני קבוצות ולצפות במצגות בקבוצות של תקני אינטרנט, כמו קבוצות העבודה של W3C.
כוונות Blink: אבני דרך והתקדמות
בכל ציון דרך שבו מהנדסים עובדים על תכונה חדשה או על שינוי במנוע הרינדור של Blink, הם מפרסמים פוסט בקבוצת הדיון blink-dev ומסבירים שהם מתכוונים לעבור לשלב הבא בתהליך ההטמעה של התכונה. הפוסטים האלה נקראים 'כוונות'. כל אחד יכול להירשם לקבוצה blink-dev כדי לקבל התראות על התקדמות בפיתוח תכונות חדשות ב-Blink, או להירשם לתכונה מסוימת כדי לקבל עדכונים.
כוונה ליצירת אב טיפוס: נקודת הבדיקה הראשונה
בשלב הזה, מהנדסי Chromium יכולים להתחיל להטמיע את התכונה. כלומר, יכול להיות שהפונקציונליות של אב הטיפוס של התכונה תהיה זמינה למפתחים לצורך בדיקה באמצעות דגל תכונת, בהתחלה ב-Chrome Canary ולאחר מכן בערוצי הפצה אחרים. כל משתמש יכול להגדיר דגל בדף chrome://flags כדי להפעיל ולבדוק תכונה בדפדפן שלו.
עם זאת, לא ניתן להגדיר את כל הדגלים דרך הדף chrome://flags. כדי לשלוט בצורה פרטנית יותר, אפשר להריץ את Chrome מסוף באמצעות דגלים של שורת הפקודה. חשוב לזכור שחלק מהתכונות החדשות לא זמינות עד שהן מועברות לבדיקה ב-Chrome Canary, אבל זה קורה לעיתים רחוקות. לחלק מהתכונות אין דגל משלהם, אבל הן זמינות אם הדגל experimental-web-platform-features מופעל. בדרך כלל זה המצב לגבי תכונות 'קטנות' שהטמעתן נמשכת לא יותר משלושה עד שישה חודשים.
איסוף משוב על אב טיפוס
לאחר תחילת תהליך היצירה של אב טיפוס של תכונה חדשה, מהנדסי Chromium מזמינים לדיונים ולניסויים מוקדמים. המשוב בשלב הזה חיוני כדי לאמת את ההצעות ולשפר אותן. בבאגים ב-Chromium אפשר לשלוח תגובות לגבי ההטמעה ב-Chrome.
כוונה לערוך ניסוי: בדיקה בעולם האמיתי
פרסום הודעה בנושא כוונה לערוך ניסוי ב-blink-dev הוא שלב אופציונלי נוסף, אם מהנדסי Chrome רוצים לבקש להפעיל גרסת מקור לניסיון.
גרסאות מקור לניסיון הן דרך לבדוק תכונה חדשה או ניסיונית בפלטפורמת אינטרנט. נרשמים לגרסה לניסיון של תכונה מסוימת, ואז מקבלים אסימון לתקופת הניסיון. התכונה תופעל בכל דף שמספק את האסימון.
אישור מהבעלים של Blink API
כדי להמשיך בתהליך ההטמעה של תכונה, הבעלים של Blink API צריכים לאשר אותה. לשם כך, הם צריכים להשיב לכוונה עם פוסט מסוג 'נראה לי בסדר', שנקרא LGTM.
בעלי Blink API הם קבוצה קטנה של שותפים ב-Chromium, שיש להם ניסיון רב בפלטפורמת האינטרנט ובממשקי ה-API שלה, וקהילת Blink אישרה שהם עומדים בדרישות, ושהם מחויבים למטרות ולערכים של Blink. בנוסף לאישור (או לדחייה) של תכונות להטמעה, בעלי ה-API אחראים על תהליך Blink Intent עצמו.
בקשה לניסוי חייבת לקבל לפחות אישור אחד (LGTM) מבעלי ה-API.
הערך של גרסאות מקור לניסיון
מפתחים יכולים להירשם לתקופת הניסיון המקורית של תכונה מסוימת, ולאחר מכן לבדוק את התכונה בסביבת הייצור בסביבות אמיתיות, עם משתמשים אמיתיים – בלי שהמשתמשים יצטרכו לבצע פעולה כלשהי כדי שהתכונה תופעל. המפתחים יכולים לשתף את התוצאות של הבדיקות שלהם, וכך לספק תובנות ונתונים חשובים שיעזרו לשפר את התכונה.
כוונה לשלוח: אבן הדרך האחרונה
הסטטוס 'כוונת השקה' מציין שהתכונה הושלמה ועכשיו היא מוכנה להטמעה לכלל המשתמשים בגרסת Chrome Stable, ללא צורך בדגל או באסימון ניסיון. כדי להמשיך בהטמעה, שלושה בעלי ממשקי API צריכים לאשר את ה-Intent to Ship.
השקה של תכונות חדשות
אחרי שהתכונה מאושרת, היא מוזגת לגרסה עתידית ולאחר מכן עוברת בערוצי ההשקה של Chrome. לרוב, אנחנו מקפידים במיוחד על בדיקה והטמעה של תכונות חדשות. חלק מהתכונות מושקות בהדרגה, לחלק הולך וגדל של משתמשים. אם יש תופעות לוואי לא צפויות, אפשר גם לבטל את הפיצ'רים ולעבד אותם מחדש.
ניהול מחזור החיים של תכונות: הוצאה משימוש והסרה
יש עוד שני סוגים של כוונות Blink:
- כוונה להוצאה משימוש
- כוונה להסרה
אולי זה נשמע קצת עצוב, אבל אלה תנאים קריטיים להצלחת הפיתוח של Blink.
מהנדסים מפרסמים הודעה על כוונה להוצאה משימוש כשהם רוצים להתחיל להזהיר מפתחים שתכונה מסוימת מתוזמנת להוצאה משימוש. לדוגמה, על ידי מתן תמיכה ומידע על ההוצאה משימוש במסוף כלי הפיתוח ל-Chrome.
הודעה על כוונה להסרה מתפרסמת כשמהנדסים מתכוונים להשבית את הקוד כברירת מחדל.
החשיבות של הוצאה משימוש והסרה
ההוצאה משימוש וההסרה הן קריטיות לבריאות פלטפורמת האינטרנט. הם מוודאים שאפשר להסיר מ-Chrome תכונות שלא עובדות טוב אצל משתמשי קצה או אצל מפתחי אתרים, ומסייעים להפחית את המורכבות של קוד הבסיס. לדוגמה, בעיות בתכנון של AppCache התגלו לאחר השימוש בו באתרי ייצור בדפדפנים יציבים, ובסופו של דבר ממשק ה-API הוסר. הסרה של תכונות ותמיכה בהן עוזרות גם לשמור על הבטיחות והאבטחה של Chrome, על ידי צמצום כיווני התקפה פוטנציאליים.
כמו בכל כוונות ה-Blink, צוות Chrome עושה כמיטב יכולתו כדי לקבל החלטות בצורה זהירה. לפני שהם ממשיכים, הם בודקים את שיעורי השימוש בתכונות ונתונים אחרים. אנחנו לא מסירים תכונות בקלות, ואנחנו מסירים תכונה רק אם רק אחוז קטן מאוד מהמשתמשים משתמש בה, ורק אם יש חלופות טובות יותר.
עדכונים על כוונות Blink
אתם יכולים לעקוב אחרי התקדמות הפיתוח של התכונות בסטטוס Chrome, שם תוכלו להירשם לעדכונים, לדווח על באגים ולמצוא מקורות מידע נוספים.
כדי לעקוב אחרי תכונות חדשות, אפשר להירשם לבלוג של Chromium. כדי להתעדכן בכל העדכונים לגבי Blink Intents, אפשר להצטרף לקבוצת הדיון blink-dev. זה עלול להוביל להמון אימיילים. לחלופין, אפשר להירשם לכוונה אחת. אפשר לראות גיליון אלקטרוני של כוונות Blink בכתובת bit.ly/blinkintents. אם אתם באמת אוהבים את התכונה 'כוונת הרכישה' ב-Blink, תוכלו להשתמש בשירותים האוטומטיים למעקב אחר כוונת הרכישה ב-Blink.
השלבים הבאים
כדאי לעיין במאמר מהם ערוצי ההפצה של Chrome?