داستان یک پروژه یا اینکه چگونه من 7 سال را صرف ایجاد یک PBX بر اساس استریسک و php کردم

مطمئناً بسیاری از شما، مانند من، ایده ای برای انجام کاری منحصر به فرد داشتید. در این مقاله مشکلات فنی و راه حل هایی را که در هنگام توسعه سانترال با آن روبرو بودم را شرح خواهم داد. شاید این به کسی کمک کند که در مورد ایده خود تصمیم بگیرد و کسی راه پیموده شده را طی کند، زیرا من نیز از تجربیات پیشگامان بهره بردم.

ایده و الزامات کلیدی

و همه چیز به سادگی با عشق شروع شد ستاره (چارچوبی برای ساخت برنامه های ارتباطی)، اتوماسیون تلفن و تاسیسات freepbx (رابط وب برای ستاره). در صورتی که نیازهای شرکت بدون مشخصات بود و در حد توان بود freepbx - همه چی عالیه. کل نصب در عرض XNUMX ساعت انجام شد، شرکت یک PBX پیکربندی شده، یک رابط کاربر پسند و آموزش کوتاه به همراه پشتیبانی در صورت تمایل دریافت کرد.

اما جالب ترین کارها غیر استاندارد بود و پس از آن آنقدرها هم افسانه نبود. ستاره می تواند کارهای زیادی انجام دهد، اما برای حفظ وضعیت رابط وب، نیاز به صرف زمان چند برابری بود. بنابراین یک جزئیات کوچک ممکن است بسیار بیشتر از نصب بقیه سانترال طول بکشد. و نکته این نیست که نوشتن یک رابط وب به زمان زیادی نیاز دارد، بلکه نکته در ویژگی های معماری است. freepbx. رویکردها و روش های معماری freepbx در زمان php4 گذاشته شد و در آن لحظه قبلاً php5.6 وجود داشت که همه چیز را می‌توان ساده‌تر و راحت‌تر کرد.

آخرین نیش پلان های گرافیکی در قالب یک نمودار بود. وقتی سعی کردم چیزی شبیه به این بسازم freepbx، متوجه شدم که باید به طور قابل توجهی آن را بازنویسی کنم و ساختن چیزی جدید آسان تر خواهد بود.

الزامات کلیدی عبارت بودند از:

• راه اندازی ساده، به طور مستقیم حتی برای یک مدیر مبتدی قابل دسترسی است. بنابراین، شرکت ها نیازی به تعمیر و نگهداری PBX در سمت ما ندارند،
• اصلاح آسان به طوری که وظایف در زمان کافی حل شوند،
• سهولت ادغام با PBX U freepbx هیچ API برای تغییر تنظیمات وجود نداشت، یعنی. برای مثال، نمی‌توانید گروه‌ها یا منوهای صوتی را از یک برنامه شخص ثالث، فقط خود API ایجاد کنید ستاره,
• منبع باز - برای برنامه نویسان این برای تغییرات برای مشتری بسیار مهم است.

ایده توسعه سریعتر این بود که همه عملکردها از ماژول هایی به شکل اشیا تشکیل شده باشد. همه اشیا باید یک کلاس والد مشترک داشته باشند، به این معنی که نام تمام توابع اصلی از قبل شناخته شده است و بنابراین از قبل پیاده سازی های پیش فرض وجود دارد. اشیاء به شما این امکان را می دهند که تعداد آرگومان ها را به شکل آرایه های انجمنی با کلیدهای رشته ای به طور چشمگیری کاهش دهید، که می توانید آن را در freepbx با بررسی کل تابع و توابع تو در تو امکان پذیر شد. در مورد اشیا، تکمیل خودکار پیش پا افتاده همه ویژگی ها را نشان می دهد و به طور کلی زندگی را چندین برابر ساده می کند. به علاوه، وراثت و تعریف مجدد بسیاری از مشکلات را با تغییرات حل می کند.

مورد بعدی که زمان دوباره کاری را کند کرد و ارزش اجتناب از آن را داشت، تکرار بود. اگر یک ماژول مسئول شماره گیری یک کارمند وجود دارد، همه ماژول های دیگری که نیاز به ارسال تماس با یک کارمند دارند باید از آن استفاده کنند و کپی های خود را ایجاد نکنند. بنابراین، اگر نیاز به تغییر چیزی دارید، باید فقط در یک مکان تغییر دهید و جستجوی "چگونه کار می کند" باید در یک مکان انجام شود و در کل پروژه جستجو نشود.

اولین نسخه و اولین خطاها

اولین نمونه در عرض یک سال آماده شد. کل PBX، همانطور که برنامه ریزی شده بود، ماژولار بود و ماژول ها نه تنها می توانستند عملکرد جدیدی برای پردازش تماس ها اضافه کنند، بلکه خود رابط وب را نیز تغییر دادند.

بله، ایده ساختن یک پلان شماره گیری در قالب چنین طرحی متعلق به من نیست، اما بسیار راحت است و من همین کار را برای ستاره.

با نوشتن یک ماژول، برنامه نویسان قبلاً می توانند:

• عملکرد خود را برای پردازش تماس ایجاد کنید، که می تواند در نمودار و همچنین در منوی عناصر در سمت چپ قرار گیرد،
• صفحات خود را برای رابط وب ایجاد کنید و الگوهای خود را به صفحات موجود اضافه کنید (اگر توسعه دهنده صفحه برای این کار فراهم کرده باشد)،
• تنظیمات خود را به برگه تنظیمات اصلی اضافه کنید یا تب تنظیمات خود را ایجاد کنید،
• برنامه نویس می تواند از یک ماژول موجود به ارث برده، بخشی از عملکرد را تغییر دهد و آن را با نام جدید ثبت کند یا ماژول اصلی را جایگزین کند.

به عنوان مثال، اینگونه می توانید منوی صوتی خود را ایجاد کنید:

......
class CPBX_MYIVR extends CPBX_IVR
{
 function __construct()
 {
 parent::__construct();
 $this->_module = "myivr";
 }
}
.....
$myIvrModule = new CPBX_MYIVR();
CPBXEngine::getInstance()->registerModule($myIvrModule,__DIR__); //Зарегистрировать новый модуль
CPBXEngine::getInstance()->registerModuleExtension($myIvrModule,'ivr',__DIR__); //Подменить существующий модуль

اولین پیاده سازی های پیچیده اولین غرور و اولین ناامیدی را به همراه داشت. خوشحالم که کار کرد، از اینکه قبلاً توانستم ویژگی های اصلی را بازتولید کنم freepbx. خوشحالم که مردم ایده این طرح را دوست داشتند. هنوز گزینه‌های زیادی برای ساده‌سازی توسعه وجود داشت، اما حتی در آن زمان برخی از وظایف از قبل آسان‌تر می‌شدند.

API برای تغییر پیکربندی PBX ناامید کننده بود - نتیجه اصلاً آن چیزی نبود که می خواستیم. من همان اصل را در نظر گرفتم freepbx، با کلیک بر روی دکمه Apply، کل پیکربندی دوباره ایجاد می شود و ماژول ها مجدداً راه اندازی می شوند.

این به نظر می رسد:

*Dialplan یک قانون (الگوریتم) است که توسط آن یک تماس پردازش می شود.

اما با این گزینه نمی توان یک API معمولی برای تغییر تنظیمات PBX نوشت. اول، عملیات اعمال تغییرات در ستاره بیش از حد طولانی و منابع فشرده
ثانیا، شما نمی توانید دو تابع را همزمان فراخوانی کنید، زیرا هر دو پیکربندی را ایجاد می کنند.
ثالثاً، تمام تنظیمات، از جمله تنظیمات انجام شده توسط مدیر را اعمال می کند.

در این نسخه، همانطور که در آسکوزیا، امکان ایجاد پیکربندی فقط ماژول های تغییر یافته و راه اندازی مجدد فقط ماژول های ضروری وجود داشت، اما همه اینها نیمی از اقدامات هستند. تغییر رویکرد ضروری بود.

نسخه دوم. بینی بیرون کشیده دم گیر کرده است

ایده حل مشکل این نبود که پیکربندی و پلان شماره گیری را دوباره ایجاد کنیم ستاره، اما اطلاعات را در پایگاه داده ذخیره کنید و هنگام پردازش تماس مستقیماً از پایگاه داده بخوانید. ستاره من قبلاً می دانستم که چگونه پیکربندی ها را از پایگاه داده بخوانم، فقط مقدار را در پایگاه داده تغییر دهید و تماس بعدی با در نظر گرفتن تغییرات پردازش می شود و عملکرد برای خواندن پارامترهای dialplan عالی بود. REALTIME_HASH.

در نهایت حتی نیازی به راه اندازی مجدد نبود ستاره هنگام تغییر تنظیمات و تمام تنظیمات شروع به اعمال بلافاصله به ستاره.

تنها تغییرات در پلان شماره گیری اضافه کردن شماره های داخلی و نکات. اما این تغییرات نقطه ای کوچک بود

exten=>101,1,GoSub(‘sub-callusers’,s,1(1)); - точечное изменение, добавляется/изменяется через ami

; sub-callusers – универсальная функция генерится при установке модуля.
[sub-callusers]
exten =>s,1,Noop()
exten =>s,n,Set(LOCAL(TOUSERID)=${ARG1})
exten =>s,n,ClearHash(TOUSERPARAM)
exten =>s,n,Set(HASH(TOUSERPARAM)=${REALTIME_HASH(rl_users,id,${LOCAL(TOUSERID)})})
exten =>s,n,GotoIf($["${HASH(TOUSERPARAM,id)}"=""]?return)
...

با استفاده از آن می توانید به راحتی خطی را در پلان شماره گیری اضافه یا تغییر دهید امی (رابط کنترل ستاره) و نیازی به راه اندازی مجدد کل طرح شماره گیری نیست.

با این کار مشکل API پیکربندی حل شد. حتی می‌توانید مستقیماً به پایگاه داده بروید و یک گروه جدید اضافه کنید یا تغییر دهید، به عنوان مثال، زمان شماره‌گیری در قسمت «زمان شماره‌گیری» گروه را تغییر دهید و تماس بعدی قبلاً مدت زمان مشخص‌شده را ادامه خواهد داد (این یک توصیه برای گروه نیست. اقدام، زیرا برخی از عملیات API نیاز دارند امی تماس می گیرد).

اولین پیاده سازی های دشوار دوباره اولین غرور و ناامیدی را به همراه داشت. خوشحال شدم که کار کرد. پایگاه داده به یک پیوند مهم تبدیل شد، وابستگی به دیسک افزایش یافت، خطرات بیشتری وجود داشت، اما همه چیز پایدار و بدون مشکل کار می کرد. و از همه مهمتر، اکنون هر کاری که از طریق رابط وب انجام می شد، از طریق API انجام می شد و از همان روش ها استفاده می شد. علاوه بر این، رابط وب از دکمه "اعمال تنظیمات برای PBX" خلاص شد، که مدیران اغلب آن را فراموش می کردند.

ناامیدی این بود که توسعه پیچیده تر شد. از زمان اولین نسخه، زبان PHP یک طرح شماره گیری در این زبان ایجاد کرده است ستاره و کاملاً ناخوانا به نظر می رسد، به علاوه خود زبان ستاره برای نوشتن طرح شماره گیری بسیار ابتدایی است.

چه شکلی بود:

$usersInitSection = $dialplan->createExtSection('usersinit-sub','s');
$usersInitSection
 ->add('',new Dialplanext_gotoif('$["${G_USERINIT}"="1"]','exit'))
 ->add('',new Dialplanext_set('G_USERINIT','1'))
 ->add('',new Dialplanext_gosub('1','s','sub-AddOnAnswerSub','usersconnected-sub'))
 ->add('',new Dialplanext_gosub('1','s','sub-AddOnPredoDialSub','usersinitondial-sub'))
 ->add('',new Dialplanext_set('LOCAL(TECH)','${CUT(CHANNEL(name),/,1)}'))
 ->add('',new Dialplanext_gotoif('$["${LOCAL(TECH)}"="SIP"]','sipdev'))
 ->add('',new Dialplanext_gotoif('$["${LOCAL(TECH)}"="PJSIP"]','pjsipdev'))

در نسخه دوم، dialplan جهانی شد، شامل تمام گزینه های پردازش ممکن بسته به پارامترها بود و اندازه آن به طور قابل توجهی افزایش یافت. همه اینها زمان توسعه را بسیار کند کرد و همین فکر که یک بار دیگر لازم است در برنامه شماره گیری تداخل ایجاد شود من را ناراحت کرد.

نسخه سوم

ایده برای حل مشکل، تولید نبود ستاره از php شماره گیری کنید و استفاده کنید FastAGI و تمام قوانین پردازش را در خود پی اچ پی بنویسید. FastAGI اجازه می دهد تا ستاره، برای پردازش تماس، به سوکت وصل شوید. دستورات را از آنجا دریافت کنید و نتایج را ارسال کنید. بنابراین، منطق dialplan از قبل خارج از مرزها است ستاره و می تواند به هر زبانی نوشته شود، در مورد من در PHP.

آزمون و خطا زیاد بود. مشکل اصلی این بود که من قبلاً کلاس ها/فایل های زیادی داشتم. ساخت اشیاء، مقداردهی اولیه و ثبت یکدیگر با یکدیگر حدود 1,5 ثانیه طول کشید و این تاخیر در هر تماس چیزی نیست که بتوان آن را نادیده گرفت.

مقداردهی اولیه باید فقط یک بار اتفاق می افتاد و بنابراین جستجو برای راه حل با نوشتن یک سرویس در php با استفاده از آن آغاز شد نخ ها. پس از یک هفته آزمایش، این گزینه به دلیل پیچیدگی های نحوه عملکرد این افزونه کنار گذاشته شد. پس از یک ماه آزمایش، مجبور شدم برنامه نویسی ناهمزمان را در PHP کنار بگذارم؛ به چیزی ساده و آشنا برای هر مبتدی PHP نیاز داشتم و بسیاری از پسوندهای PHP همزمان هستند.

راه حل، سرویس چند رشته ای خودمان در C بود که با آن کامپایل شده بود PHPLIB. تمام فایل‌های php ATS را بارگذاری می‌کند، منتظر می‌ماند تا همه ماژول‌ها مقداردهی اولیه شوند، یک callback به یکدیگر اضافه می‌کند، و وقتی همه چیز آماده شد، آن را کش می‌کند. هنگام پرس و جو توسط FastAGI یک جریان ایجاد می شود، یک کپی از حافظه نهان تمام کلاس ها و داده ها در آن تکثیر می شود و درخواست به تابع php ارسال می شود.

با این راه حل، زمان ارسال تماس به سرویس ما تا اولین فرمان ستاره از 1,5 ثانیه به 0,05 ثانیه کاهش یافت و این زمان کمی به اندازه پروژه بستگی دارد.

در نتیجه، زمان توسعه dialplan به طور قابل توجهی کاهش یافت، و من می توانم از این قدردانی کنم زیرا مجبور شدم کل پلان شماره گیری همه ماژول ها را در PHP بازنویسی کنم. اولاً، برای به دست آوردن یک شی از پایگاه داده، روش ها باید قبلاً در php نوشته شده باشند؛ آنها برای نمایش در رابط وب مورد نیاز بودند، و ثانیاً، و این نکته اصلی است، در نهایت می توان به راحتی با رشته ها با اعداد و آرایه ها کار کرد. با پایگاه داده به علاوه بسیاری از پسوندهای PHP.

برای پردازش dialplan در کلاس ماژول باید تابع را پیاده سازی کنید dialplanDynamicCall و استدلال pbxCallRequest شامل یک شی برای تعامل خواهد بود ستاره.

علاوه بر این، اشکال زدایی dialplan ممکن شد (php دارای xdebug است و برای سرویس ما کار می کند)، می توانید با مشاهده مقادیر متغیرها قدم به قدم حرکت کنید.

داده های تماس

هر گونه تجزیه و تحلیل و گزارش نیاز به داده های جمع آوری شده صحیح دارد و این بلوک سانترال نیز از نسخه اول تا سوم آزمون و خطاهای زیادی را پشت سر گذاشت. اغلب، داده های تماس یک نشانه است. یک تماس = یک ضبط: چه کسی زنگ زد، چه کسی جواب داد، چه مدت صحبت کردند. در گزینه های جالب تر، یک علامت اضافی وجود دارد که نشان می دهد کدام کارمند PBX در طول تماس فراخوانی شده است. اما همه اینها تنها بخشی از نیازها را پوشش می دهد.

الزامات اولیه عبارت بودند از:

• نه تنها از کسانی که سانترال تماس گرفته اند، بلکه از کسانی که پاسخ داده اند نیز صرفه جویی کنید، زیرا شنودهایی وجود دارد و این باید در هنگام تجزیه و تحلیل تماس ها در نظر گرفته شود،
• زمان قبل از برقراری ارتباط با یک کارمند که در freepbx و برخی از سانترال های دیگر، به محض اینکه سانترال تلفن را برمی دارد، به تماس پاسخ داده می شود. اما برای منوی صوتی از قبل باید تلفن را بردارید، بنابراین به همه تماس ها پاسخ داده می شود و زمان انتظار برای پاسخ 0-1 ثانیه می شود. بنابراین، تصمیم گرفته شد نه تنها زمان قبل از پاسخ، بلکه زمان قبل از اتصال با ماژول های کلیدی ذخیره شود (خود ماژول این پرچم را تنظیم می کند. در حال حاضر "کارمند"، "خط خارجی" است).
• برای یک پلان شماره گیری پیچیده تر، زمانی که یک تماس بین گروه های مختلف انجام می شود، لازم بود بتوانیم هر عنصر را جداگانه بررسی کنیم.

بهترین گزینه زمانی است که ماژول های PBX اطلاعات مربوط به خود را در تماس ارسال می کنند و در نهایت اطلاعات را به شکل درخت ذخیره می کنند.

به نظر می رسد به این شکل است:

اول، اطلاعات کلی در مورد تماس (مثل بقیه - چیز خاصی نیست).

1. تماسی در یک خط خارجی دریافت کرد "برای آزمون"در ساعت 05:55:52 از شماره 89295671458 به شماره 89999999999 در پایان توسط یکی از کارکنان پاسخ داده شد"منشی 2» با شماره 104. مشتری 60 ثانیه صبر کرد و 36 ثانیه صحبت کرد.
2. کارمند "منشی 2"با 112 تماس می گیرد و یک کارمند پاسخ می دهد"مدیر 1» بعد از 8 ثانیه. آنها 14 ثانیه صحبت می کنند.
3. مشتری به کارمند منتقل می شود "مدیر 1جایی که آنها 13 ثانیه دیگر به صحبت کردن ادامه می دهند

اما این نوک کوه یخ است؛ برای هر رکورد می توانید تاریخچه تماس دقیقی را از طریق PBX دریافت کنید.

تمام اطلاعات به صورت تودرتویی از تماس ها ارائه می شود:

1. تماسی در یک خط خارجی دریافت کرد "برای آزمون» در ساعت 05:55:52 از شماره 89295671458 به شماره 89999999999.
2. در ساعت 05:55:53 خط خارجی یک تماس به مدار ورودی ارسال می کند.آزمون»
3. هنگام پردازش یک تماس طبق طرح، ماژول "تماس مدیر"، که در آن تماس 16 ثانیه است. این ماژول توسعه یافته برای مشتری است.
4. مدول "تماس مدیر"به کارمند مسئول شماره (مشتری) تماس می فرستد"مدیر 1” و 5 ثانیه منتظر پاسخ می ماند. مدیر جوابی نداد
5. مدول "تماس مدیر"برای گروه تماس می فرستد"مدیران CORP" اینها دیگر مدیران همسو هستند (در یک اتاق نشسته اند) و 11 ثانیه منتظر پاسخ هستند.
6. گروه "مدیران CORP"با کارمندان تماس می گیرد"مدیر 1, مدیر 2, مدیر 3"به طور همزمان به مدت 11 ثانیه. بدون پاسخ.
7. تماس مدیر به پایان می رسد. و مدار یک تماس به ماژول ارسال می کند "انتخاب مسیر از 1c" همچنین یک ماژول نوشته شده برای مشتری. در اینجا تماس به مدت 0 ثانیه پردازش شد.
8. مدار یک تماس به منوی صوتی ارسال می کند.پایه با شماره گیری اضافی" مشتری 31 ثانیه در آنجا منتظر ماند، شماره گیری اضافی وجود نداشت.
9. این طرح یک تماس به گروه ارسال می کند "منشی ها"، جایی که مشتری 12 ثانیه منتظر ماند.
10. در یک گروه، 2 کارمند به طور همزمان فراخوانی می شوند.منشی 1"و"منشی 2"و بعد از 12 ثانیه کارمند پاسخ می دهد"منشی 2" پاسخ به تماس در تماس های والدین کپی می شود. معلوم می شود که در گروه او پاسخ داد "منشی 2"، هنگام تماس مدار پاسخ داده شد"منشی 2"و به تماس در خط بیرونی با " پاسخ دادمنشی 2'.

صرفه جویی در اطلاعات مربوط به هر عملیات و تودرتوی آنهاست که امکان تهیه گزارش را به سادگی ممکن می سازد. گزارشی در منوی صوتی به شما کمک می‌کند تا بفهمید چقدر به شما کمک می‌کند یا مانع آن می‌شود. گزارشی از تماس های بی پاسخ کارمندان تهیه کنید، با در نظر گرفتن اینکه تماس رهگیری شده است و بنابراین از دست رفته تلقی نمی شود و با در نظر گرفتن اینکه تماس گروهی بوده و شخص دیگری زودتر پاسخ داده است، یعنی تماس نیز از دست نرفته است.

چنین ذخیره سازی اطلاعات به شما این امکان را می دهد که هر گروه را به طور جداگانه انتخاب کنید و میزان کارآمدی آن را تعیین کنید و نموداری از گروه های پاسخ داده شده و از دست رفته را بر حسب ساعت بسازید. همچنین می توانید با تجزیه و تحلیل نقل و انتقالات پس از اتصال به مدیر، دقت کنید که ارتباط با مدیر مسئول چقدر است.

همچنین می‌توانید مطالعات کاملاً غیرمعمولی را انجام دهید، برای مثال، تعداد دفعاتی که شماره‌هایی که در پایگاه داده نیستند، پسوند صحیح را شماره‌گیری می‌کنند یا چند درصد از تماس‌های خروجی به تلفن همراه ارسال می‌شوند.

نتیجه؟

برای نگهداری سانترال نیازی به متخصص نیست؛ معمولی ترین مدیر می تواند این کار را انجام دهد - در عمل آزمایش شده است.

برای اصلاحات، نیازی به متخصصان با شرایط جدی نیست، دانش PHP کافی است، زیرا ماژول هایی قبلاً برای پروتکل SIP و برای صف و برای فراخوانی یک کارمند و دیگران نوشته شده است. یک کلاس لفاف برای وجود دارد ستاره. برای توسعه یک ماژول، یک برنامه نویس می تواند (و به روشی خوب باید) ماژول های آماده را فراخوانی کند. و دانش ستاره اگر مشتری بخواهد صفحه ای با گزارش جدید اضافه کند، کاملا غیر ضروری هستند. اما تمرین نشان می دهد که اگرچه برنامه نویسان شخص ثالث می توانند با این کار کنار بیایند، اما بدون مستندات و پوشش عادی نظرات احساس ناامنی می کنند، بنابراین هنوز جای پیشرفت وجود دارد.

ماژول ها می توانند:

• ایجاد قابلیت های پردازش تماس جدید،
• اضافه کردن بلوک های جدید به رابط وب،
• از هر یک از ماژول های موجود به ارث برده، توابع را دوباره تعریف کرده و جایگزین کنید، یا به سادگی یک کپی اصلاح شده باشد.
• تنظیمات خود را به قالب تنظیمات ماژول های دیگر و موارد دیگر اضافه کنید.

تنظیمات PBX از طریق API. همانطور که در بالا توضیح داده شد، تمام تنظیمات در پایگاه داده ذخیره می شوند و در زمان تماس خوانده می شوند، بنابراین می توانید تمام تنظیمات PBX را از طریق API تغییر دهید. هنگام فراخوانی API، پیکربندی دوباره ایجاد نمی شود و ماژول ها دوباره راه اندازی نمی شوند، بنابراین، مهم نیست که چند تنظیمات و کارمند دارید. درخواست های API به سرعت اجرا می شوند و یکدیگر را مسدود نمی کنند.

سانترال تمام عملیات کلیدی را با مدت زمان تماس (انتظار/مکالمه)، تودرتو و به زبان PBX (کارمند، گروه، خط خارجی، نه کانال، شماره) ذخیره می کند. این به شما امکان می دهد تا گزارش های مختلفی را برای مشتریان خاص بسازید و بیشتر کار ایجاد یک رابط کاربر پسند است.

زمان نشان خواهد داد که در ادامه چه اتفاقی خواهد افتاد. هنوز تفاوت های ظریف زیادی وجود دارد که باید دوباره انجام شود، هنوز برنامه های زیادی وجود دارد، اما یک سال از ایجاد نسخه 3 می گذرد و می توان گفت که این ایده کار می کند. نقطه ضعف اصلی نسخه 3 منابع سخت افزاری است، اما این چیزی است که شما باید برای سهولت توسعه هزینه کنید.

منبع: www.habr.com