עוד חדשות טובות מחברנו הוותיק WebRTC.
ליתר דיוק: שלוש חדשות טובות וכמה שינויים קלים ב-API.
RTCDataChannel עבור Chrome
RTCDataChannel יושם ב-Chrome, ויש הדגמה קטנה ונהדרת ב-simpl.info/dc.
בהדגמה הזו מוצגת תקשורת מקצה לקצה (P2P) של נתונים שרירותיים – בפחות ממאה שורות קוד. נדרש Chrome 25 ומעלה כדי לבצע את הפעולה הזו, ובשלב הזה זה אומר בטא או Canary.
RTCDataChannel מפיק את המיטב מהפיצ'רים המובנים ב-RTCPeerConnection – ובמיוחד הוא השימוש של מסגרת ICE כדי לעבור דרך חומות אש ו-NATs – ויש לו המון יישומים פוטנציאליים שבהם זמן האחזור נמוך חיוני: למשחקים, ליישומי שולחן עבודה מרוחקים, לצ'אט טקסט בזמן אמת ולהעברת קבצים.
למידע נוסף על RTCDataChannel, כדאי לקרוא את המאמר תחילת העבודה עם WebRTC.
שינויים ב-API
זה פחות מלהיב, אבל עדיין חשוב: החל מגרסה Chrome 26, חלק מהתכונות של RTCPeerConnection ו-MediaStream API הפכו ל-getter method:
- ב-MediaStream יש עכשיו השיטה
getAudioTracks()במקום הנכס audioTracks, ו-getVideoTracks()במקום הנכסvideoTracks. - ל-RTCPeerConnection יש עכשיו
getLocalStreams()במקוםlocalStreamsו-getRemoteStreams()במקוםremoteStreams.
כדי לקבל הצצה ל-MediaStream בפעולה, תוכלו להציץ בהדגמה של simpl.info/gum getUserMedia. המשתנה stream נמצא בהיקף גלובלי: אפשר לבדוק אותו מהמסוף. בדומה ל-RTCPeerConnection בכתובת simpl.info/pc: האובייקטים של RTCPeerConnection pc1 ו-pc2 נמצאים בהיקף גלובלי.
Chrome <=> Firefox
בנוסף במקרה במקרה שהחמצתם את זה, Chrome יכול כעת 'לדבר' עם Firefox.
תוכלו לנסות את זה עכשיו בכתובת webrtc.org/start, שכולל הוראות מלאות, קישורים לקוד המקור ומידע על הבדלים ב-API.
לכל מי שגורם לכל זה לקרות ב-Mozilla וב-Google.
קידוד מהנה! ניתן להודיע לנו על באגים כלשהם על ידי הוספת תגובה לפוסט הזה או על ידי שליחת תגובה לכתובת bugs.chromium.org. וחשוב לזכור שתמיד אפשר לקבל מידע עדכני על ההטמעה מהכתובת המעולה chromestatus.com.