לשרת שאני כותב יש שני ממשקי ניהול, ממשק וובי וממשק טלנט.
הממשק הוובי יותר ידידותי כמובן, אבל ממשק הטלנט מהיר יותר, גמיש יותר וקל יותר להוסיף לו פקודות.
חשבתי לתומי שיהיה ממש נחמד לאפשר גישה לממשק הטלנט דרך הממשק הוובי.
הייתי בטוח שיש משהו כזה כבר, בדקתי כל מני פרוייקטים כמו anyterm,
ajaxterm ועוד כמה, אבל כולם כללו רכיב שרת והיה קשה לחלץ מהם את הקוד של צד הלקוח ולממשק אותו לשרת שלי.
בסוף הבזבוז זמן, החלטתי לנסות לממש כזה, ובעזרתו האדיבה של עמיתי לעבודה שגיא מעוז, כתבנו את הפלאגין Ajax terminal, פלאגין-JQuery פשוט במיוחד לשימוש ולהטמעה.
הרעיון הוא פשוט, הלקוח שולח שורה לשרת, השרת עושה מה שעושה ושולח תשובה ללקוח. הלקוח לוקח את התשובה ודוחף אותה בטרמינל.
הטרמינל תוכנן להראות בדיוק כמו טרמינל לינוקס, כדי שיהיה קולי במיוחד.
[code lang="html"]
[/code]
הקוד של השרת הספציפי של הטרמינל הזה מאוד פשוט ומפגר, ורק ממחיש כמה קל להתממשק לטרמינל:
[code lang="php"]
[/code]
כמובן שאפשר לממש עם זה כל מני דברים מעניינים..
אולי צ'אט?
אולי tail לקובץ לוג על השרת?
סתם פקודות שונות ומשונות?
כל העסק משוחרר תחת רשיון MIT או GPL (כמו של JQuery).
הרעיון שלי, אבל רוב הקוד של שגיא, וגם היוזמה לשחרר את זה כפלאגין JQuery. כבוד למגזר.
ממשק שורת פקודה, או מסך מלא?
מימוש של מסוף אמיתי זה הרבה קצת יותר מסובך ממה שיש לכם כאן. לדוגמה: שורת פקודה עם השלמה עם לחיצה על טאב (או מקש אחר) לא תעבוד כאן.
נקודה נוספת: כל התווים שנשלחים למסוף נשלחים בפועל כבקשות לאפאצ'י. אם בין השאר מזדהים שם ע"י הקשת סיסמאות או מקלידים נתונים רגישים אחרים, רצוי לוודא שהנתונים הללו לא יגיעו ללוגים של אפאצ'י. התיעוד של ajaxterm ממליץ (עם דוגמה פשוטה) לדאוג לא לשמור לוגים מהבקשות למסוף.
צודק, זה לא טרמינל מלא אבל זה נותן את הפונקציונליות החשובה וזה מה שחשוב.
היתרון של הגישה הפשוטה הזו הוא שהשרת הוא טריוויאלי לחלוטין, וקל לכתוב אותו בכל שפה שהיא (לא צריך ספריה מורכבת שמממשת VT100 או משהו דומה בצד השרת).
ברירת המחדל היא לשלוח את הנתונים בPOST, אז הם לא יגיעו ללוג של אפאצ'י.
אגב, אפאצ'י הוא רק שרת אפשרי אחד כמובן, אפשר להשתמש בכל טכנולוגיה בצד השרת.
שימו לב שכשכותבים פקודה שאינה קיימת התשובה שחוזרת הא ההפוכנה לטקסט שנכתב. (כלומר אם אני אכתוב abc יצא cba)
זה בכוונה?
Ddorda, כן. כמו שכתוב אם אתה מקליד help או מסתכל בקוד הPHP (רחמנה ליצלן 🙂 )
מימוש של tail -f לא יעבוד בדוגמה הזו, מאחר והלקוח מבקש מידע מהשרת רק באופן יזום. כדי לממש tail -f אתה צריך להוסיף פונקציה שתופעל כל x שניות באופן אוטומטי ותבדוק אם לשרת יש משהו חדש להודיע לנו, וזה לא יהיה פשוט כל עוד השרת לא יודע מהי פיסת המידע האחרונה שהוא שלח.
לא אמרתי שזה פשוט.
אבל זה בהחלט יהיה מגניב.
השרת יכול לדעת מה פיסת המידע האחרונה שהוא שלח בכמה שיטות:
1. קוקי שנשלח לקליינט.
2. STATE בשרת, אולי קובץ FIFO?
בכל מקרה, זה יעבוד אחרת מהטרמינל הזה, אבל זה בהחלט אפשרי.
עזוב, בוא נעשה משהו יותר מעניין.
כמעט כל האתרים הישראלים הגדולים כוללים צ'אט. מרביתם עושים זאת באמצעות יישומי ActiveX או Java (בעיקר בגירסה של מיקרוסופט, כך שגם אם יש לך ג'אווה מותקן על המכונה בכלל לא בטוח שתצליח להיכנס). לאחרונה הם התחילו לגלות את פלאש, אבל גם זה לא הפתרון האולטימטיבי (איטיות, בעיות עם העברית וכו'). לצרה הזו תוסיף את חוסר היכולת להשתמש בכל תוכנה מאחר וחסר ובארץ אנחנו צריכים גם RTL. אני חושש שבעתיד הקרוב הם יתחילו לחשוב לכיוון של שדרוג המערכות ל־Silverlight שזו תהיה צרה חדשה שנצטרך להתמודד איתה.
מה אני מציע? להרים פרוייקט קוד פתוח לבניה של מערכת צ'אט חופשית, שתכלול מהבסיס תמיכה בכל הדברים המעניינים שאנחנו יכולים לעשות עם ajax, תמיכה בסמיילים ובקישורים, תמיכה מובנית בעברית ואנגלית וכדומה, ולתת להם להשתמש בה ישירות על השרתים שלהם ללא צורך ברישיונות יקרים. דבר זה יוריד את התלות בתוכנות של מיקרוסופט לקבוצת משתמשים נוספת.
אם מישהו רוצה להרים כזה פרוייקט – הוא מוזמן להודיע לי. אשמח לקחת חלק בכזו יוזמה.
איך אתה רוצה לפתור את בעיית tail -f ללא poll?
איך אתה רוצה לקבל ביצועים סבירים (אינטראקטיביות סבירה ושימוש סביר בזמן מעבד ורוחב פס) עם poll?
צפריר – מה שגוגל ואחרים עושים במקרים כאלה הוא לחזות את זמני ה־poll המשוערים, ובכל משיכה לנסות לחזות מחדש את מועד המשיכה הבאה. למשל, אם תוכנה של tail -f רואה ששורות חדשות מתווספות רק באינטרוול של פעם בדקה – אין שום סיבה לנסות לבדוק אם קיימים נתונים חדשים בפרקי זמן קצרים יותר, אבל מאחר ופעם בדקה זה עיכוב משמעותי מידי והמשתמש עלול להרגיש בכך, מגדירים מראש את פרק הזמן המינימלי והמקסמלי למשיכת נתונים, למרות שהתוכנה יכולה לקבוע את אינטרוול המשיכה בניהם בעצמה.
צפריר:
נניח שאני שולח לקליינט את המיקום האחרון של סוף הקובץ עם כל תשובה (או בעצם את גודל הקובץ).
כשהקליינט מתחבר הוא מוסר את המיקום ואני יכול בקלות לשלוח לו את מה שחדש אם יש (ובצורה יעילה לגמרי).
עד כאן זה פשוט, וזה גם עונה לך על השאלה השניה.
לגבי השאלה הראשונה:
אני יכול להשתמש בבתשובת HTTP מתמשכת.
למה הכוונה?
הקליינט מתחבר, ואני שולח לו את מה שיש לשלוח ועושה FLUSH.
במקום לסגור את החיבור בשרת, אני משאיר אותו פתוח ובודק פעם בשניה מה הגודל של הקובץ. אם השתנה אני שולח עוד וכמובן עושה FLUSH.
אם הקליינט התנתק בגלל TIMEOUT או חרא אחר, באחריותו להתחבר מחדש (ולמסור את המיקום האחרון שהוא קיבל בקובץ) כדי להמשיך לעקוב אחרי הקובץ.
היי,
אפרופו דיון ה- tail -f.
המונח הכללי לדחיפת מידע מהסרבר לקליינט מעל HTTP נקרא comet:
http://en.wikipedia.org/wiki/Comet_(programming)
בעתיד, תקן HTML5 אמור לכלול web sockets, פתרון שיהיה סטנדרטי יותר מכל ספריות ה- AJAX אי שם + יעיל יותר משום לא יתבסס על HTTP (אני רואה כאן פונטציאל בעייתי של סינון ע"י FW יודעי קרוא וכתוב HTTP).
http://www.indicthreads.com/3625/html-5-websocket-cracks-the-http-request-response-barrier/
היי גילי,
לא ידעתי שהמציאו שם לכל העניין הזה.
המימוש שבחרתי לTAIL -F הוא המימוש המתבקש והפורטבילי ביותר של בקשת XHR שיושבת על השרת עד שיש לו מה להחזיר, וחוזר חלילה.
לגבי HTML 5:
עוד חזון למועד, לא חושב שנראה את זה הופך למציאות בשנים הקרובות.