מחלקת "תכנות נורמלי במערכות 'ימות'..."

MusiCode

כבר כולם בטח קראו את החזון שלי, שתהיה מחלקה נורמלית לתכנות מערכות בAPI ימות.
המטרה שקוד למערכות בימות ייראה כך:

call = new yemotCall(apiCallId)
call.playFile("file")
f = call.read("file", 1, 5, ...)
call.goToFolder("/7/" + f)
call.hangup()

אלו הנתונים:
המשתמש נכנס לשלוחה, והשלוחה שולחת בקשה לשרת, "מה לעשות איתו?".
השרת עונה תשובה, השלוחה מבצעת, ומיד שלוחת שוב בקשה - "ומה עכשיו?" עם נתוני הפעולה הקודמת.
בכל בקשה, נשלח מזהה השיחה של המשתמש, המשתנה בכל שיחה למערכת.

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

f = call.read("file", 1, 5, ...)
call.goToFolder("/7/" + f)

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

אז אני מניח שזה לא אמור להיות תהליך-משנה של ממש לכל משתמש,
אלא יותר בכיוון של אירועים וקולבקים.

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

nigun

@MusiCode
נראה לי שאני מתחיל להבין מה אתה מנסה לבנות

אתה רוצה לבנות מערכת בימות המשיח ושתצטרך לעשות שלוחה API אחת בלבד

כיום המצב הוא שאם אתה נותן תשובה של id_list_message בלי תפריט הוא משמיע את הקובץ
וחוזר שלב אחד אחורה או לשלוחה אחרת שאתה כותב בgoToFolder
ואם אתה בונה את כל המערכת בשלוחות נפרדות זה מקשה לך על הבניה וגם קצת קשה לשמור את המשתנים שהלקוח יצר בשלב קודם כי צריך לשמור את זה במסדי נתונים ולנהל את השליפה ואת המחיקה בסוף השיחה וכו'
הפתרון שלך הוא לנהל סוג של תהליך שמוקצה למזהה שיחה הנוכחי ובו נשמרים כל הנתונים הרלוונטים לשיחה ואם השמעת למאזין קובץ אחרי ההשמעה הוא חוזר לקריאה נוספת אבל עכשיו הוא לא ישמע קובץ אלא ישמע תפריט אחרי שהוא בוחר מה שבחר הוא חוזר שוב לשרת ושם אתה עונה לו עם if else את התשובה הרלוונטית ואפילו יכול לשלוח אותו לשלוחת API אחרת שמאפסת את כל הסטרינג שנשלח בGET
זה נראה לי מתאים בעיקר למערכות בסגנון של מכירות
האם הבנתי אותך נכון?

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

nigun

@MusiCode
לעצם הרעיון בא ננסה להגדיר איך זה יעבוד
אם הבנתי נכון אתה רוצה להתחיל תהליך עם קריאת HTTP ואחר כך לתת פקודות/ערכים נוספים לתהליך עם קריאת HTTP נוספת
אני שאלתי משהו בסגנון כאן
ואחר כך שאלתי בפורום אחר (gopher.slack)

I'm trying to build web api that will start processes and kill them with separate calls Something like this

package main
import (
    "fmt"
    "net/http"
)
  func run(w http.ResponseWriter, req *http.Request) {
    
go run(foo)
})
    func kill(w http.ResponseWriter, req *http.Request) {
    
go kill(foo)
})
func main() {
  
   http.HandleFunc("/run", run)
   http.HandleFunc("/kill", kill)
    http.ListenAndServe(":8080", nil)
}

Is it possible?

וענו לי משהו בכיוון שכתב @yossiz

Tim G. 11:13 PM
you can implement a logic like that with channels or atomic functions but I don’t think you can make it work since each request runs in its own space but can’t talk to each other.
you can store the PID when you run on a request and kill the process with that PID once you get the kill call though.

האם התכוונת למשהו במבנה הזה או שיש דרך אחרת לשמור את הערכים בזיכרון?

dovid

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

MusiCode

@dovid אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

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

@MusiCode אמר במחלקת "תכנות נורמלי במערכות 'ימות'...":

אלו הנתונים:
המשתמש נכנס לשלוחה, והשלוחה שולחת בקשה לשרת, "מה לעשות איתו?".
השרת עונה תשובה, השלוחה מבצעת, ומיד שלוחת שוב בקשה - "ומה עכשיו?" עם נתוני הפעולה הקודמת.
בכל בקשה, נשלח מזהה השיחה של המשתמש, המשתנה בכל שיחה למערכת.

עוד הרחבה?
בבקשה.
המשתמש נכנס לשלוחה מסויימת.
מיד השלוחה שולחת בקשה לשרת שלי, ואת הפקודה שאני אתן, היא תבצע למאזין (השמעת קובץ, או קבלת הקשות).
איך שיסתיים ביצוע הפקודה, היא שולחת עוד בקשה, לפקודה חדשה שתבוצע.
את התוצאות אם יש מהפקודה הקודמת, היא שולחת כפרמטרי GET בבקשה החדשה.
זה נראה ככה:
בקשה ראשונה: https://call2yemot.com/ext
התשובה: read=f-000=ivr,n,...
(המילה הראשונה read היא מסמנת קבלת הקשות. אח"כ, שם הקובץ שיושמע כתפריט. אח"כ שם המשתנה שיוחזר)
בקשה שנייה: https://call2yemot.com/ext?ivr=2
המאזין הקיש שתיים.
נענה לו: go_to_folder=/1/5
לך לשלוחה 1/5.

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

MusiCode

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

f = call.read("file", 1, 5, ...)

והקוד ימשיך לשורה הבאה

call.goToFolder("/7/" + f)

MusiCode

אולי אם מישהו מבין איך אסטריסק ARI עובד,
אפשר לשכפל את זה גם לכאן.
https://github.com/asterisk/node-ari-client

הרעיון הוא, שכל אירוע שקורה במערכת, נשלח ע"ג ווב-סוקט ללקוח ה-ARI,
ואופן שליחת הפקודות למערכת, הוא HTTP.

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

על אסטריסק-ארי: https://wiki.asterisk.org/wiki/display/AST/Introduction+to+ARI+and+Channels

nigun

@MusiCode

עדיין לא הבנתי איך אתה מקשר בין הקריאה החדשה לתהליך שמחכה ואיך הוא ידע איפה לעצור ואיפה להמשיך
בPHP אתה יכול לעצור את התהליך עם תנאי שלא ימשיך הלאה כל עוד התנאי לא התקיים
אבל כאן נראה לי שאתה רוצה לחסוך את השימוש בתנאי
כפי הידוע לי ימות שולחים בקשה עם curl או משהו מקביל ופשוט כל פעם מוסיפים עוד ערך לסטרינג
לכן לא נראה לי ששייך לעשות כאן ווב-סוקט כמו באסטריסק
למשל בAGI אם אני שולח שתי פקודות א-סינכרוניות להקראת קובץ מסויים בהפרש של 2 שניות
המערכת מתחילה להקריא את הקובץ הראשון למשך 2 שניות ואז מפסיק ועובר לקובץ השני
וזה לא אפשרי כמובן בימות המשיח

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

MusiCode

@nigun לא התכוונתי לעשות ווב-סוקט...
רק שאם שם יש אופציה של קטע קוד שמבוצע בהתאמה לכמה קריאות (שם - ווב-סוקט, כאן - בקשות HTTP), אז זה בדיוק מה שרציתי.

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

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

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

yossiz

@MusiCode איפה בבקשה של ימות אתה מקבל את מזהה השיחה?

nigun

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

nigun

@MusiCode
אני בור בנוד
אבל אולי אני אלמד מזה משהו

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

MusiCode

@MusiCode אמר ב[מחלקת "תכנות נורמלי במערכות

זה נראה ככה:
בקשה ראשונה: https://call2yemot.com/ext
התשובה: read=f-000=ivr,n,...
(המילה הראשונה read היא מסמנת קבלת הקשות. אח"כ, שם הקובץ שיושמע כתפריט. אח"כ שם המשתנה שיוחזר)

למעשה הבקשה הראשונה נראית כך:
https://call2yemot.com/ext?ApiPhone=0504100000&ApiCallId=b6t76r7v6v4754c

nigun

@MusiCode
ליתר דיוק
ApiCallId=0b1b92e09984f1d6f200e3190b805a6ab0625f68&ApiDID=0773137777&ApiRealDID=0773137777&ApiPhone=0504100000&ApiExtension=5/1

yossiz

@MusiCode מה שאתה צריך הוא מימוש של generator ~~coroutines~~ .

משהו כזה:

var activeCalls = {};

function router(req, res) {
    var callId = getCallId(req);
    var currentCall = activeCalls[callId];
    if (currentCall) {
        var returnedValue = extractValue(req);
    } else {
        currentCall = activeCalls[callId] = Call();
        returnedValue = null;
    }
    var reply = currentCall.next(returnedValue);
    return res.send(reply.value);
}

function* Call() {
    yield playfile("file");
    var f = yield read("file", 1, 5, ...);
    yield goToFolder("/7/" + f);
    yield hangup();
}

אני לא מצרף מימוש של playfile, read, gotofolder, hangup כי אין לי מושג איך ה-API של ימות עובד. אבל כל אחד מפונקצייות אלו אמור להחזיר את המחרוזת שצריך להשיב למערכת ימות

yossiz

בהמשך להנ"ל,
בינתיים השתמשתי רק בקוד סינכרוני בתוך פונקציית call. אבל בחיים האמתיים תצטרכו מן הסתם קוד איסינכרוני.
מאז נוד 10 ומעלה אפשר להשתמש ב-Asynchronous generators.
זה נראה כך,

var activeCalls = {};
 
async function router(req, res) {
    var callId = getCallId(req);
    var currentCall = activeCalls[callId];
    if (currentCall) {
        var returnedValue = extractValue(req);
    } else {
        currentCall = activeCalls[callId] = Call();
        returnedValue = null;
    }
    var reply = await currentCall.next(returnedValue);
    return res.send(reply.value);
}
 
async function* Call() {
    yield playfile("file");
    var f = yield read("file", 1, 5, ...);
    yield goToFolder("/7/" + f);
    yield hangup();
}

אני מקווה ללמוד יותר את ה-API של ימות ואז אוכל להביא משהו יותר מושלם.

yossiz

איזה מחרוזת שולחים כדי לסיים את השיחה בימות?
אני מנסה לעשות סוג של hello world עם yield כדי להדגים צורת הפעולה

@MusiCode האם הקוד הנ"ל עונה על דרישותיך? הפונקציה call נראה כמעט כמו הקוד שלך רק בתוספת המילה yield.

nigun

@yossiz
החיבור יכול להסתיים במעבר לשלוחה אחרת
ואז לא נשלח כלום
ואם הלקוח ניתק את השיחה כשהוא עדיין בשלוחת API המערכת תשלח את כל הערכים שנאספו עד עכשיו בשלוחה בתוספת hangup=yes

yossiz

@nigun אני שואל מה אני אמור לשלוח כדי לנתק את השיחה מהצד שלי?
(בקיצור מימוש של פונקציה בשם hangup)

nigun

@yossiz
שולחים את המשתמש לשלוחת ניתוק
(לא ידוע לי על דרך אחרת)

תחומים - פורום חרדי מקצועי

מחלקת "תכנות נורמלי במערכות 'ימות'..."