קטגוריה: Opera

webrtc ORTC

הקדמה

במידה ולא הכרתם, יש בעולם הHTML5 (באזז וורד בפני עצמו) טכנולוגיה מדהימה לזרימת מדיה בשם webrtc (אשר אפילו אני מספק עבורה פתרונות).

הרעיון הוא לקחת SDP ו RTP (שכמובן מכיל RTCP) ולאפשר להזרים אודיו ווידאו בצורה טבעית בדפדפן ללא שימוש בתוספים.
הטכנולוגיה גם מגיעה עם תמיכה ב STUN, ICE ו TURN.

היא תומכת ב OPUS, ו G711, ומחייבת אותנו לעבוד בצורה מאובטחת תחת DTLS,

עכשיו כל מה שנשאר זה לממש מערכת סיגנלים כדוגמת SIP או כל פתרון אחר – פשוט יותר עם web sockets,שגם הוא כיום (לפי התקן של webrtc) חייב כבר להיות מאובטח תחת TLS, ויש לנו פיתרון סטרימינג מלא.

אבל יש בעיה: SDP הוא אחד הפרוטוקולים הכי לא קריאים שיש, ובנוסף ישנו תיאור של מידע יחסית ארוך.

SDP הם ראשי תיבות של Session Description Protocol. התפקיד של הפרוטוקול הוא לספק מידע אודות המדיה, כדוגמת אילו קודקים נתמכים, מה כתובת התעבורה למדיה, ואפילו מה החלק של המדיה שנשלח, כלומר איפה הוא מבחינת התחלת "לוחות זמנים", האם אני מקבל את ההחלה, או משהו אחר.

הדגמה קלה (מה RFC):

v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=.
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000

הסדר של השדות משנה, השדות עצמן כפי שניתן לראות קריפטיות לגמרי לקריאת בני אדם, וגם מסתבר שלא באמת כזה פשוט ליצור לכך מפרש נורמאלי בלי להשתמש במאפיינים של מפרש לקסלי בשפת תכנות כדוגמת  yacc.

הנה הסבר על מה שאתם רואים מול העיניים שלכם:
האות v, מייצגת version – גרסת הפרוטוקול, שלפחות כרגע היא תמיד 0.
האות o, מייצגת origin של הבקשה, ומכילה (לפי הסדר) – שם משתמש, session id, בנוסף session-version, סוג רשת (אינטרנט), סוג הכתובת, כתובת הרשת.
האות s מייצגת את session, כלומר השם שלו.
האות c מייצגת מידע על connection. זה אומר סוג הרשת, סוג כתובת הרשת, כתובת הרשת.
הכוונה היא לאן רוצים להתחבר בשביל המדיה.
האות t מייצגת זמנים.
האות m מייצגת מדיה, עם סוג מדיה, פורט דינאמי, פרוטוקול משלוח של המדיה, ומידע הקשור לפרוטוקול.
האות a מייצגת attribute, שזה תכונות שונות, למשל כאן, זה מייצג איזה קוקדים של אודיו ישלחו, כולל הקוד שלהם שמוגדר ב RFC עבור כל סוג קודק.

אפשר לראות כמה זה לא קריא וידידותי, אבל גם מגביל מאוד.
למשל attribute יכול להגיע רק לחלק מהפרמטרים, ויש פרמטרים שחייבים אותו. הוא תמיד חייב להיות מתחת לאותו פרמטר.

אף אחת מהאותיות לא יכולה להיות ריקה, ולכן במידה ונגיד שלא נרצה לייצג את שם ה session, יהיו אלו שישימו שם תו כמו נקודה או מינוס. אסור גם רווחים עם הסימן שווה מאיזשהו כיוון, ורשימת החוקים עוד ארוכה.

בנוסף ישנם פרמטרים אשר בכלל לא נגעתי בהם בפוסט שקיימים בנוסף, וגם להם חוקים שונים.

תוכן

אז למה אני נכנס לכל זה ?
ובכן בעולם ה webrtc, רוצים לרדת מ SDP לגמרי. כאן ציינתי חלק גדול מהסיבות לכך. אפילו מיקרוסופט חיבקה את הרעיון והודיעה שזו הדרך שלה להיכנס לעולם הזה, שכרגע נשלט בעיקר על ידי גוגל (כרום) ומוזילה, מבחינת דפדפנים, אך גם אופרה תומך בזה.

לפני ORTC, תכננו פרוטוקול אחר לגמרי, אשר היה מאוד low level, ומאוד קשה להגנה, וסיפק יותר מידי כוח בצד המשתמש. הפרוטוקול קיבל את השם Open Peer. אז בגלל הסיבות האלו, החליטו לרדת ממנו.

ואז ישבו הרבה אנשים, אשר רובם יצרו את webrtc ואת Open Peer, והחליטו על גרסה 1.1 לwebrtc בכנס מסחרי מסוים, אם כי למרות ההכרזה על 1.1 ההכרזה מרגישה יותר כמו 2.0.
השם לפרוטוקול החדש באותו כנס, קיבל את השם ORTC או Object Real Time Communication, אשר ה draft הראשון (מבחינת יכולת מימוש) שלו שוחרר באוגוסט 2014.
היכולת לעקוב אחרי דברים, נעשת באתר ייעודי לכך בשם ortc.org.

הרעיון הוא לספק סוג של API, שמצד אחד קל לתכנות, ומצד שני קל לאבטח, אשר מאפשר לשלוט בצורה קלה ופשוטה יותר במידע על המדיה, כאשר יש API בצד ה javascript, אך גם עם תאימות לאחור, בשביל לא לשבור פתרונות קיימים.
אבל לא סתם API, אלא הדגש הוא על גישה של Object Oriented, כאשר בעבר דיברו על כך שהיא תכלול את היכולת להחזיק אובייקטים של סוקטים בשם RTCSocket אשר ניתנים לשימוש מחודש במידת הצורך, ובכך בעצם לעשות שימושיות ב RTC ללא צורך באתחול מחודש של הכל. אך אינני מוצא זאת בdraft האחרון (נכון לכתיבת פוסט זה).

ישנם הרבה תיאוריות קונספירציה בנושא, למשל שמיקרוסופט עומדים מאחורי זה בשביל לגרום לגוגל לאבד את היתרון שלהם בנושא, או שזה בעצם קונספירציה בסגנון של תחרות בפרוטוקולים, אך נראה כי דווקא כלל השחקנים שקובעים את הפרוטוקולים כולל גוגל עצמה בעד.

הבעיה היא שORTC הוא סוג של API שבסוף משתמש ב SDP (אבל רק בהתחלה – תאימות לאחור) ואח"כ כנראה שיפרד מהגישה הזו. אבל הם עוד לא בטוחים בזה. כלומר הרעיון שלהם, הוא שבסופו של דבר לא יהיה SDP, אלא דיבור ישיר בין ה"ענן" (מערכת כלשהי שאתם תבנו בצד השרת) לבין הדפדפן, ואיכשהו יוחלט מה יורץ.

זה רעיון נחמד, אבל איך הוא מתבצע כאשר אין לך SDP ?
התשובה פשוטה – אתה תממש משהו כזה מחדש, ואתה תספק לו שם חדש, למשל השם Media Information Protocol או משהו בסגנון.

ואכן, זה מה שORTC מבצע. הם יצרו אובייקט בשם RTCRtpCapabilities, אשר התפקיד שלו לדבר על "מה אני צריך" עם הצד השני וניתן אפילו לעשות החלפה בזמן ריצה של המידע (ב SIP זה נקרא re-Invite).

אך כמו שניתן להבין, זה לא באמת מובן וזה עדיין כללי מידי, כלומר, מה הפרוטוקול בפועל שיהיה במקום ?
לכן כרגע יש לחכות, או להיות שותפים בנושא ולנסות להשפיע (בהצלחה עם זה).

יש עודף שאלות פתוחות לדעתי בנושא, והוא לא באמת כזה ברור בשלב הנוכחי, והוא צריך עוד להתבשל ולהתפתח יותר.

אבל הגישה הזו של ORTC ובעצם שכתוב של חלק מאוד חשוב ב webrtc גורם לכך כי במקום לסייע לאנשים לאמץ את webrtc, מרבית השוק כרגע מנסה להתעלם ממנו לגמרי, וזה רק מעקב את האימוץ הזה, אך האם המאמץ הזה יהיה שווה ? רק ימים יגידו.

אז מה דעתי בנושא ?
מצד אחד, אני חושב ש SDP זה כאב ראש. מצד שני, אני לא עד הסוף סגור על הרעיון של ORTC, ולכן אני לא ממהר לקפוץ ולהגיד שזה טוב או רע, רק מפריע לי שהוא שונה כל כך מהתקן הקיים היום (שעדין ב draft), היות ולי אישית כבר יש מימושים בנושא.

אל תתנו להם לחוקק חוקים – חוק הנגשת אתרים

"The more corrupt the state, the more numerous the laws." — Tacitus

הקדמה

בסוף שנות ה90 ותחילת אמצע שנות ה2000, דפדפן אחד של מערכת הפעלה אחת שלט בעולם.
הדפדפן הזה קיבל את השם Internet Explorer, אשר כמו מגלה ארצות ה"מכבד" את עצמו, הכריח את כולם לעבוד לפי הלך החשיבה של החברה שיצרה אותו, במקום לעמוד בתקנים ולהכיר בתרבויות השונות שאליהם הוא נקלע.
אנחנו זעקנו בהרבה מאוד קולות שצריך לכתוב אתרים לפי תקן, ולא לפי דפדפן.
בישראל, מרבית העסקים, שלא לדבר על הממשלה, התעלמו לגמרי מהפניות שלנו. אפילו מאמרים שונים בעיתונות לטובת הדרישה שלנו, זכו להתעלמות.

רק כאשר מספר מקומות הבינו כי למרות שדפדפנים כדוגמת Firefox מהווים פחות מ5% מהתעבורה, אבל מהווים 90% מכוח הקנייה, שראינו שינוי מגמה.
פתאום אתרים התחילו להיות מונגשים לFirefox תחילה, היות והוא זה שהכניס כסף. אבל בשביל להיות תואם Firefox, כל מה שצריך זה לפתח לפי תקנים (תודה מוזילה), ולכן למעט באגים של הדפדפן, אם אתה כותב לפי התקן, תיאורטית זה אמור לעבוד עבור כולם.
בנתיים גם השימוש ב data עבור הסלולר גדל, ודפדפן Opera Mini תפס, וגם החברה הזו בחרה לעבוד עם תקנים, וראו איזה פלא, לא צריך לשכתב דברים (למעט התאמה לסוג תצוגה).

אם זה לא היה מספיק, Firefox הציג לנו גם חידושים אמיתיים בחווית השימוש, משהו שמיקרוסופט לא טרחו בכלל לספק, וככזה הוא הפך להיות נוח יותר, והאחוזים שלו תפסו יותר.
ב2008 יצא עוד דפדפן מבית גוגל בשם Chrome, והוא כבר התחיל שינוי אמיתי. הוא כבר נגיש יותר, ועובד גם לפי תקנים, לפעמים אפילו לפני שהם יוצאים, ולמעשה גוגל הצליחו להביא למצב בו למעט ארגונים גדולים, הרבה מעדיפים לעבוד עם הדפדפן שלהם, אשר לפחות למראית עין, הוא "מהיר" יותר.

כיום למעט 2 דפדפנים עיקריים, מרבית הדפדפנים מבוססים על אותו בסיס (אשר משתנה לאט לאט שוב), בשם Webkit, אשר התחיל בכלל את דרכו כ KHTML עבור פרוייקט KDE כדפדפן בשם Konqueror.

למרבה הצער, כיום רק אתרים כדוגמת בנק הפועלים ואתרי הממשלה אינם באמת תומכים במשהו שהוא לא Internet Explorer. בבנק הפועלים בחשבון עסקי, אתה חייב שהוא יהיה 32 ביט. בעוד שבאתרי ממשלה שונים, אתה חייב ש IE יהיה גרסה 6.

העיקר להמשיך לקרוא

fpWeb סקירה ראשונית

fpWeb הוא framework מעניין לעבודה עם אפליקציות מבוססות web כדוגמת web services (עם תמיכה ב JSON, JSONRPC1, JSNORPC2, XMLRPC ועם תוסף, גם תמיכה ב SOAP) וכן עבודה גמישה שדורשת התממשקות למסדי נתונים ויצירת מידע המבצע תצוגה כממשק web ב HTML.

הסביבה יודעת לספק לנו אפשרות לפתח אפליקציה או כCGI על שלל גווניה (ז"א cgi רגיל ו fast cgi), וכן גם כמודול לאפצ'י. בנוסף הספרייה יודעת להתממשק לLazarus ובכך לספק פיתוח קצת יותר גרפי עבור האפליקציה עם שימוש ב"חלונות" כדוגמת DataModule ו"חלון" מיוחד לצד השרת עצמו (החלון קיים רק בזמן תכנון ולא בזמן ריצה).

הספרייה כוללת יכולות עבודה מרמת ה HTTP הפשוטה ביותר (כולל תמיכה בעוגיות, session, עבודה עם פרמטרים, שליטה ב"ראש" ועוד הרבה אפשרויות אחרות), ועד עבודה מול templates, כאשר העבודה נעשת בגישה של פיתוח מבוסס אירועים, כלומר על בסיס כל אירוע כותבים קוד במקום ליישם הכל ולפרק לבד את העבודה.

כמו כן, המיפוי של נתיבים נעשה באמצעות path info, אבל אם אתם מעוניינים לעבוד בגישה באתר של העסק שלי, אז לצערי שם יש קצת יותר עבודה, היות והוא לא תוכנן לגישה הזו במקור, וחבל. אבל אם השפה היתה בסוף במקום בהתחלה, אז היה קל מאוד בצורה הנוכחית לעשות את זה, כך שגמישות של נתיבים זה נושא שדורש חשיבה מעט שונה מאשר framework כדוגמת סינטרה, Rails ואפילו DJango.

הגישה לפיתוח עם Templates מספק אפשרות במידה ורוצים לא לעבוד בגישה של ברירת המחדל להגדיר איך משתנה נראה בעצם ב template, זה אומר איך אני מייצג פתיחה וסגירה שלו, האם הוא יכול להיות משתנה מקונן, כלומר משתנה שהוא בעצם סוג של תנאי, או סוג של מידע, וכאשר הוא בתוך משתנה אחר, כיצד לזהות אותו שם, וכיצד להתמודד עם מידע אשר מכיל גם html "רגיל" וגם משתנה עצמו.

העניין הוא אבל הגישה של העבודה עם משתנים. הגישה אומרת שבמקום שהלוגיקה נעשת בtemplate, היא נעשת בצד של הקוד שלנו בשרת. כלומר המשתנים אינם מכילים לוגיקה אלא מייצגים גישה של מידע מסויים ואנחנו בוחרים איך בדיוק המשתנים האלו יהפכו לאותו מידע. זו גישה שונה מאשר לוגיקה של erb והרבה טמפלטים אחרים, שלא לדבר על שפה כדוגמת PHP, אשר מגיעה כשפת inline.

זה אומר שאם אני רוצה לעשות עכשיו רשימה של 10 איברים, הוא לא ידע שמדובר ב10 איברים, אבל הקוד שלי כן, ואני אחליף את המשתנה לפי הלוגיקה שיש ברשותי ואזין את המידע בהתאם, והוא רק יחליף בסיום הריצה את המשתנה עם המידע שלו בפנים למה שיצרתי.

עוד דבר שחשוב מאוד בגישה של הframwework, הוא שחשיבה היא עבור כמה שפחות עבודה מול השרת וכמה שיותר גישה לצד הלקוח, אבל ללא צורה מחייבת באמת (כלומר יש לי את הגמישות לשנות את הגישה הזו), והרעיון הוא להשתמש בכמה שפחות משאבים עבור כמה שיותר בקשות, אם כי אני לא בדקתי אף פעם את הביצועים.

עוד דבר שחשוב לדעת, הוא שהתמיכה בframework היא עבודה מתמשכת, וכל הזמן נוספים לה עוד יכולות ולפעמים גם יש שינויים.

אני רק התחלתי ללמוד את הסביבה, אבל אני חייב לציין שהיא מאוד מעניינת בפני עצמה, ואשמח לעוד זמן ללמוד יותר לעומק את הסביבה.

זמן הפיתוח של אתרי אינטרנט

כשהייתי בגיל העשרה אדם אשר ידע לתכנת (לבנות תוכנות) בגילי, נחשב ל"גאון מחשבים". כיום כל ילד אשר יודע לעשות copy paste מול תוכנה ששומרת לך את התוצאה בתור HTML מוגדר כעילוי (לפחות ע"י אנשים אשר לא מבינים).

אז חשבתם פעם מה נדרש בשביל לבנות אתר אינטרנט ?

ובכן, אתר אינטרנט המכיל דף סטטי, מאוד פשוט לבנייה כאשר משתמשים בHTML3.2, אבל כאשר משתמשים ב CSS וxhtml הדברים מתחילים להראות טיפה יותר מסובכים.

למזלנו הטוב מרבית הדפדפנים החדישים יודעים כיצד לטפל בצורה נכונה (למעט באגים כמובן) בקוד שכתוב נכון, כך שההשקעה שצריכה להתבצע לרוב לא דורשת מאמץ מיוחד עבור דפדפן ספציפי.

ובכן, זה נכון למרבית הדפדפנים פרט לדפדפן אחד: Internet Explorer. למרות שכולם הולכים לכיוון של הדפדפן הספציפי בגלל פופולריות תמוהה של מערכת ההפעלה של עליה הדפדפן רץ, הדפדפן עצמו דורש הרבה יותר מידי השקעה בשביל ליצור אתר שיתאים. הבעיה כל כך חמורה שכל תת גרסה של הדפדפן תתנהג בצורה שונה מגרסה אחרת.

הרבה יותר זול ומהיר לפתח אתר אינטרנט שירוץ על הדפדפנים Firefox, Opera, Konqueror/Safai מאשר אתר שיתאים את עצמו לכל גרסאות ה IE.

ואם זה לא מספיק, אז הנה גרף שמראה את הבעיות של פיתוח אתרי אינטרנט.