सभी क्लाउड पुश सेवाओं के लिए एक PHP एपीआई

सभी पाठकों को नमस्कार। वेब विकास में बहुत सारे रुझान हैं जिनका आप अनुसरण नहीं कर सकते हैं। लेकिन साइट के उपयोगकर्ताओं के साथ वास्तविक समय की बातचीत का सवाल किसी भी परियोजना के लिए एक तीव्र रीड है। सबसे आसान तरीका व्यापक रूप से उपलब्ध खुले धूमकेतु-सर्वरों में से एक है, उदाहरण के लिए, Dklab_Realplexor, Socket.IO या Faye - जो आपको पसंद है या प्रौद्योगिकी स्टैक पर निर्भर करता है। सच है, यह काफी जटिल परियोजनाओं का रास्ता है जहां टीम इस तरह के समाधान का खर्च उठा सकती है।

कई परियोजनाओं के लिए, यह सरल है (हालांकि यह हमेशा आवेदन विशिष्टता का मामला है) तीसरे पक्ष के समाधान का उपयोग करना तर्कसंगत होगा। और एक सेवा के रूप में धूमकेतु-सर्वर कार्यक्षमता किराए पर लेना आसान है। आज ऐसी सेवाओं की कोई कमी नहीं है, इसलिए हमारे पास समीक्षा के लिए कुछ है।

और इसलिए, पहले, आइए मौजूदा धक्का सेवाओं की संक्षिप्त जांच करें जो हमें अपने क्लाइंट इन्फ्रास्ट्रक्चर को बनाए और बनाए बिना प्रोजेक्ट क्लाइंट के बीच वास्तविक समय संचार बनाए रखने की अनुमति देगा।

केवल 6 ऐसी सेवाएं हैं: पुशर , पबनब , पार्टक्ल , बीकनपश , एक्स- स्ट्रीम.ली और ioBridge (कुछ विशेषताओं के साथ)। कटौती के तहत - सभी सेवाओं का एक संक्षिप्त अवलोकन, उनके लिए PHP पुस्तकालयों की विशेषताएं और सभी क्लाउड पुश सेवाओं के साथ काम को एकीकृत करने के लिए pushBridge.IO पुस्तकालय का विवरण।

Pusher.com

इन सेवाओं में सबसे प्रसिद्ध है। इसी समय, अवसरों की प्रचुरता के कारण यह सबसे कठिन में से एक है। सामान्य शब्दों में, संचार को चैनलों में विभाजित किया गया है, जिसके भीतर उपयोगकर्ता घटनाएं हैं जो क्लाइंट कोड (जावास्क्रिप्ट) की सदस्यता लेती हैं। इसके अलावा, कई सिस्टम ईवेंट हैं, साथ ही साथ अन्य चैनल उपयोगकर्ताओं की स्थिति और अलर्ट और कनेक्शन / डिस्कनेक्ट की एक प्रणाली भी है। निजी चैनलों के साथ काम करना भी संभव है, ताकि एक जुड़ा उपयोगकर्ता जो कोड पहचानकर्ता को नहीं जानता है, उसे इवेंट्स प्राप्त नहीं होंगे।

अन्य प्रणालियों के साथ बातचीत करने के लिए, पुशर REST-HTTP-API (हालांकि, सभी समान सेवाओं की तरह) का उपयोग करता है, और क्लोजर, ग्रूवी और कोल्डफ्यूजन सहित 11 भाषाओं के लिए कई तैयार लाइब्रेरी प्रदान करता है। मुझे केवल PHP एपीआई में दिलचस्पी थी, जिसे 4 प्लगइन्स द्वारा दर्शाया गया है - कोहना, कोड इग्नाइटर और सिम्फनी 2 फ्रेमवर्क के लिए एक बंडल, साथ ही साथ एक स्वतंत्र वर्ग ( http://github.com/squeeks/Pusher-PHP )। काम करने के लिए, इसे एक्सटेंशन cURL और json, साथ ही sha256 को हैश एल्गोरिथ्म की आवश्यकता होती है।

एक नोट के रूप में, मैं कहूंगा कि यह इस सेवा से था कि मेरे पुस्तकालय के बारे में विचार आया था। मैं ईमानदार रहूंगा - एक परियोजना के लिए मुझे वास्तविक समय की आवश्यकता थी, लेकिन मैं अपने सर्वर को परीक्षण संस्करण में नहीं लिखना चाहता था, इसलिए कुछ मिनटों में मैंने एक पुशर को जोड़ने के बारे में सोचा, खासकर जब से मेरा पहले से ही एक खाता था। यह पता चला कि सभी फायदे और प्रलेखन की प्रचुरता के साथ, प्रणाली इतनी सरल नहीं है, और सभी क्षणों को अच्छी तरह से चित्रित नहीं किया गया है। डिबग मोड में बहुत मदद मिली जब कंसोल अनुभाग में साइट पर एपीआई के माध्यम से भेजे गए आपके सभी अनुरोध वास्तविक समय में प्रदर्शित होते हैं। लेकिन कहीं मैंने पैर सेट किया और यद्यपि अनुरोध भेजे गए, वे क्लाइंट तक नहीं पहुंचे। इस बिंदु पर, डिबगिंग के एक घंटे के बाद, मैंने इस चीज को छोड़ दिया। मुझे कोड को फिर से लिखने की संभावना पसंद नहीं थी, और इसके अलावा, अपनी परियोजना के अंतिम संस्करण में, मुझे अभी भी अपने स्वयं के सर्वर पर स्विच करना होगा। तो विचार आया - आपको हर बार सब कुछ फिर से लिखने की आवश्यकता क्यों है, अगर आप एक एकीकृत इंटरफ़ेस में सब कुछ कम करने की कोशिश कर सकते हैं। आगे देखते हुए, मैं कहूंगा कि विचार को सफलतापूर्वक इसका कार्यान्वयन मिल गया है!

PubNub.com

यह सेवा सरल है और, इसमें मुझे इसका फायदा दिखता है। एपीआई बेहद सरल है - इसमें चैनल, संदेश और वे सब हैं। डेटा प्रारूप, निश्चित रूप से, हर जगह JSON है। क्लाइंट साइड और सर्वर साइड दोनों पर, पबनब का व्यापक कवरेज है, जो किसी भी प्लेटफ़ॉर्म और प्रोग्रामिंग भाषा पर सेवा तक पहुंच प्रदान करता है। सभी प्लेटफार्मों की सादगी और शक्तिशाली समर्थन इस सेवा को उन लोगों के लिए सबसे दिलचस्प बनाता है, खासकर यदि आपको हर जगह वास्तविक समय प्रदान करने की आवश्यकता है।

सेवा तक पहुँचने के लिए PHP लाइब्रेरी काफी सरल है, यह दोनों को CURL पर आधारित संदेश भेजने और प्राप्त करने की अनुमति देता है। यह PHP के 5.2 और 5.3 दोनों संस्करणों पर काम करता है; मैं कॉलबैक फ़ंक्शन जैसे बन्स का उपयोग करने की अनुमति देता हूं। स्रोत कोड पर शोध करने के बाद, बड़ा सवाल बना रहा - किसी कारण से, जब भेजने के बाद, JSON में कनवर्ट करने के बाद, संदेश की लंबाई 1800 वर्ण नहीं होनी चाहिए! इस सीमा का क्या कारण है यह अभी तक स्पष्ट नहीं है, मैं डेवलपर्स से संपर्क कर पता लगाऊंगा।

Partcl.com

इस बाजार में एक नई सेवा, शुरू में एक वेब पेज पर वास्तविक समय अद्यतन टैग एम्बेड करने पर केंद्रित थी। वर्तमान में, एपीआई वहाँ काफी विस्तारित है और आपको मूल्यों में परिवर्तन का इतिहास प्राप्त करने की अनुमति देता है, ग्राफ़ का निर्माण करता है जो वास्तविक समय में भी काम करते हैं, आदि। अन्य सेवाओं के विपरीत, केवल संचार के रूप में तैनात, Partcl एक सामग्री प्रदाता के रूप में भी काम करता है, सभी संदेशों और डेटा को संग्रहीत करता है, जो एक अद्वितीय कार्य है। कुछ विवरणों को प्रकट करते हुए, मैं कहूंगा कि सर्वर भाग Node.JS + Redis (यह वास्तविक समय "वितरक" - मैं इसका तत्काल डेवलपर हूं) में लिखा है, और वेब भाग Zend फ्रेमवर्क पर है।

हालांकि सिस्टम के लिए पहले से ही एक PHP एपीआई लिखा गया था, और यहां तक ​​कि वर्डप्रेस में एकीकरण के लिए एक प्लगइन, यह मेरे मानकों द्वारा, काफी आदिम था और कुछ होस्टिंग सेवाओं पर काम नहीं कर सकता है। इसलिए मैंने partcl के लिए एक नया पुस्तकालय कार्यान्वयन लिखने की कोशिश की। यह मूल से भी बेहतर निकला।

BeaconPush.com

एक अल्पज्ञात सेवा, लेकिन केवल एक जो ग्राहकों की मांग के लिए एक समर्पित सर्वर प्रदान करता है (सिस्टम, वैसे, जावा में लिखा गया है)। और इसलिए, यह सामान्य है, हालांकि चैनलों और संदेशों के अलावा, यह उपयोगकर्ता के अमूर्तपन को भी लाता है, विशिष्ट जुड़े ग्राहकों के बीच संचार को सरल बनाता है। इसके अलावा, वेब हुक की एक दिलचस्प कार्यक्षमता तब होती है जब सेवा स्वयं आपके द्वारा निर्दिष्ट URL को खींचती है, उपयोगकर्ताओं को चैनल में प्रवेश करने / बाहर निकलने के बारे में संकेत देती है। प्रकाशन क्षमताओं को नियंत्रित करना भी संभव है - यदि आप इसे सक्षम नहीं करते हैं, तो किसी को भी, सार्वजनिक आईडी को जानकर, डेटा प्रकाशित करने में सक्षम होगा, अन्यथा केवल एक गुप्त कुंजी होने पर।

लेकिन PHP एपीआई के साथ, यह सेवा किसी भी तरह से काम नहीं करती थी। बेशक, ( https://github.com/ImDom/BeaconPush-PHP और यहां तक ​​कि कोड इग्नाइटर के लिए एक मॉड्यूल है), लेकिन गुणवत्ता ... अच्छे से बहुत दूर है। वैसे, मॉड्यूल के लेखक ने स्रोत में अपने खाते को सीवे किया। ईमानदारी से एक तैयार किए गए मॉड्यूल का उपयोग करने की कोशिश कर रहा है, लेकिन इसे सही तरीके से काम करने के लिए कॉन्फ़िगर नहीं कर सकता है (बेवकूफ ने मेरी खाता आईडी को स्वीकार करने से इनकार कर दिया), मैंने Zend_Http के तहत इसके एपीआई को पूरी तरह से फिर से लिखा है।

X-Stream.ly

एक और लगभग अज्ञात सेवा, हालांकि, जिसमें कई दिलचस्प विशेषताएं हैं। उदाहरण के लिए, आप विशेष रूप से एपीआई (जाहिरा तौर पर व्यापार मॉडल के कारण) के लिए विशिष्ट उपयोगकर्ताओं की पहुंच को विनियमित करने के लिए कुंजी बना सकते हैं। इसके अलावा, यह केवल एक ही है, जिसमें पार्थक को छोड़कर, जिसमें स्थायी संदेश भंडारण की कार्यक्षमता है। अन्य विशेषताएं कम या ज्यादा मानक हैं - चैनल, इवेंट, पासवर्ड एक्सेस के साथ निजी चैनल, उपयोगकर्ता की स्थिति। एक अनूठी विशेषता ट्विटर फीड है, जब सेवा स्वयं निर्दिष्ट ट्विटर खाते से कनेक्ट होगी और सभी जुड़े हुए उपयोगकर्ताओं को नए संदेश प्रसारित करेगी। चैनल में दिखाई देने वाले संदेश की स्थिति में, आप कॉलबैक डाल सकते हैं, जिसे REST-API के माध्यम से भी नियंत्रित किया जा सकता है। वैसे, यह सेवा केवल वही है जो अपने HTTP एपीआई के अलावा, अपने HTTP एपीआई में प्रकाशित (और आम तौर पर एक्सेस) को प्रकाशित करने के लिए, आपके खाते के उपयोगकर्ता नाम और पासवर्ड का उपयोग करके HTTP प्राधिकरण की आवश्यकता होती है, साथ ही केवल एक SSL कनेक्शन के माध्यम से काम करता है, जो बनाता है अतिरिक्त होस्टिंग आवश्यकताओं।

सर्वर का मूल सर्वर API अल्प से अधिक है - C #, रूबी, और Node.JS। मुझे खरोंच से उनके एपीआई के हिस्से को लागू करना था, इसलिए यहां मैं पहला पुस्तकालय लिख रहा हूं।

ioBridge.com

सबसे दिलचस्प और अजीब सेवा, धक्का भी नहीं। यह सभी प्रकार की ग्रंथियों को वेब (नियंत्रकों और बोर्डों) से जोड़ने पर केंद्रित है, और यह वेब के माध्यम से डेटा डिस्प्ले, संग्रह और भंडारण और नियंत्रण भी प्रदान करता है। PHP पर कोई मूल ग्राहक नहीं है, आधिकारिक मंच में कोड के कई सुझाव और ड्राफ्ट हैं, लेकिन वे एक गुणवत्ता कार्यान्वयन से बहुत दूर हैं। हां, और मुझे समझ में आया कि, इसे स्वयं करना क्यों शुरू किया - सेवा स्थानों में बहुत ही अजीब है, उदाहरण के लिए, विजेट और सत्र आईडी की कार्रवाई प्राप्त करने के लिए, आपको उनके सर्वर से एक अनुरोध करने की आवश्यकता है, जो तुरंत HTML + जावास्क्रिप्ट का एक टुकड़ा लौटाता है, जिसमें से आपको बेवकूफों के बेवकूफ पार्सिंग के साथ डेटा प्राप्त करने की आवश्यकता होती है। , जो तब कमांड को जोड़ने और भेजने के लिए आवश्यक हैं। दुर्भाग्य से, मैं मूल कोड से आगे नहीं बढ़ सका, जाहिर है, पूर्ण परीक्षण के लिए, मुझे डिवाइस को स्वयं कनेक्ट करना होगा। इसलिए इस कोड का वास्तविक परिस्थितियों में परीक्षण नहीं किया जाता है, अगर किसी के पास सेवा के साथ अनुभव है, तो मैं सुझावों और सभी संभव सहायता के लिए आभारी रहूंगा।

और अब सबसे महत्वपूर्ण बात के बारे में - pushBridge.IO PHP लाइब्रेरी

PHP के लिए मेरी लाइब्रेरी को इन सेवाओं में से प्रत्येक के उपयोग के लिए सभी मूल पुस्तकालयों को बदलने के लिए डिज़ाइन किया गया है, मूल कार्यक्षमता के साथ सीधे काम करने की क्षमता बनाए रखते हुए, मूल कार्यक्षमता के लिए एक एकल और सामान्य इंटरफ़ेस प्रदान करता है (उन मामलों के लिए जब यह है)। कुछ सेवाओं के लिए, यह सबसे अच्छा या शर्मनाक नहीं है, सबसे अच्छा पुस्तकालय (कम से कम PHP में)।

अब तक, केवल मूल कार्यक्षमता को लागू किया गया है - जहां इसे आवश्यक है, कनेक्ट करना और अधिकृत करना, और निर्दिष्ट चैनल पर एक संदेश भेजना या उपयोगकर्ता घटना उत्पन्न करना। अन्य सभी विशिष्ट कार्यों को सीधे कनेक्शन वर्ग के एक उदाहरण से प्राप्त किया जा सकता है। अगले संस्करण में, इसे फिर से लिखा जाएगा ताकि अन्य लोगों के पुस्तकालयों पर निर्भर न रहें और सभी कार्यों के लिए एक एकल इंटरफ़ेस प्रदान करें (जुड़े उपयोगकर्ताओं की संख्या, संदेश इतिहास, संदेश पढ़ना, आदि)।

लाइब्रेरी को दो भागों में विभाजित किया गया है - बेस क्लास वांछित एडाप्टर को इनिशियलाइज़ करने के लिए जिम्मेदार है, मैसेज को प्रोसेस करता है, और यदि आवश्यक हो, तो इसे सीरियल करता है। इसके लिए, मैंने Zend_Serializer वर्ग का उपयोग किया, इसलिए इसके सभी स्वरूपों का समर्थन किया जाता है - नियमित Json से लेकर विदेशी Wddx तक।

एडेप्टर वर्ग विशिष्ट सेवाओं के साथ काम करने के लिए जिम्मेदार है, जो यदि आवश्यक हो, तो देशी पुस्तकालय को जोड़ता है। अब तक, मूल वर्गों को केवल पुशर और पबनब के लिए उपयोग किया जाता है, इस तथ्य के कारण कि सेवाएं अपने विशिष्ट कार्य प्रदान करती हैं जो अभी तक पोर्ट नहीं की गई हैं। लेकिन आरंभीकरण के बाद, आप हमेशा गेटकनेक्शन () पद्धति को कॉल करके सीधे काम करना जारी रख सकते हैं।

मैंने प्राधिकरण के लिए डेटा को किसी तरह से एकीकृत करने का भी प्रयास किया। कुछ सेवाएँ app_id और एक गुप्त कुंजी का उपयोग करती हैं, अन्य उन्हें प्रकाशित और सदस्यता / सार्वजनिक कुंजी आदि कहते हैं। इसलिए, मैंने उन्हें न्यूनतम सेट पर कम करने और सभी सेवाओं के लिए एक नाम रखने की कोशिश की:

• appId - यह आमतौर पर एक एप्लिकेशन आईडी या एपीआई कुंजी है, जो किसी खाते या एप्लिकेशन के लिए एक विशिष्ट पहचानकर्ता है
• CortKey - गुप्त कुंजी जो डेटा प्रकाशित करने का अधिकार देती है
• secretKey - अपने खाते तक पहुंचने के लिए पासवर्ड या अन्य गुप्त कुंजी
• readKey - क्लाइंट के रूप में कनेक्ट करने और डेटा पढ़ने के लिए सार्वजनिक कुंजी
• emailKey - ई-मेल के रूप में उपयोगकर्ता लॉगिन (अब तक यह विशेष रूप से x-Stream.ly के लिए है)

पुस्तकालय के साथ काम करने के लिए, तीन लाइनें पर्याप्त हैं:

1. प्रारंभिक और कनेक्शन।

$push = new pushBridge_IO( [ Adapter ], [serializer] );

पहला पैरामीटर आपके लिए आवश्यक सेवा के लिए एडाप्टर उदाहरण है, उदाहरण के लिए:

new pushBridge_Adapter_Pusher(Array('appId' => 'Your app Id', 'authKey' => 'Your key', 'secretKey' => 'Your secret key', 'debug' => true));



आमतौर पर, केवल प्राधिकरण डेटा पर्याप्त होता है, जिसका सेट सेवा के लिए विशिष्ट होता है। लेकिन पुस्तकालय, मूल वर्गों के विपरीत, Zend_Http से नेटवर्क स्टैक का उपयोग करके कनेक्शन विधियों के लचीले नियंत्रण की अनुमति देता है। अनुरोधों के लिए, आप प्रॉक्सी के माध्यम से काम करने के लिए cURL, सीधे सॉकेट या एडेप्टर का उपयोग कर सकते हैं। डिफ़ॉल्ट रूप से, cURL का उपयोग किया जाता है, लेकिन यदि आपको आवश्यकता है, तो एडेप्टर नाम को httpAdapter पैरामीटर, और httpAdapterConfig में किसी भी सेटिंग को ZF प्रलेखन ( उदाहरण के लिए, यहां ) के अनुसार पास करें । मैं स्वीकार करता हूं कि इस बिंदु पर वर्तमान लाइब्रेरी कार्यान्वयन में अभी भी एक बग है, जबकि एडेप्टर के लिए उपयोगकर्ता द्वारा निर्धारित विकल्पों का उपयोग नहीं किया जाता है, यह अगले संस्करण (दूसरे दिन) में तय किया जाएगा।

चूंकि विभिन्न सेवाओं के लिए (या इसके विपरीत) अलग-अलग तरीकों की आवश्यकता होती है, आप विधि पैरामीटर में निर्दिष्ट कर सकते हैं कि एडाप्टर सर्वर से कैसे कनेक्ट होगा। यह आमतौर पर GET है, लेकिन कभी-कभी सेवाएँ केवल POST को समझती हैं। एडेप्टर इसे ध्यान में रखता है, लेकिन आप इस पैरामीटर को ओवरराइड कर सकते हैं।

पुस्तकालय अपने कस्टम हेडर को अनुरोध में, एक्स-पावर्ड-बाय, स्वयं की पहचान करते हुए सम्मिलित करता है, यदि वांछित है, तो इसे नेटवर्क ट्रैफ़िक या बस सिद्धांत से बाहर निकालने के लिए बंद किया जा सकता है।

दूसरा पैरामीटर धारावाहिक है जो संदेश को संसाधित करेगा। सभी सेवाएँ JSON स्वीकार करती हैं, या (कुछ, उदाहरण के लिए, Partcl) सिर्फ एक स्ट्रिंग, रूपांतरण के बिना। प्रारंभ में, Zend_Serializer वर्ग का उपयोग करके json है, हालांकि आप इसे किसी अन्य के साथ ओवरराइड कर सकते हैं। यह दूसरे पैरामीटर के रूप में पास करने के लिए पर्याप्त है या तो धारावाहिक के नाम के साथ एक स्ट्रिंग (अब हम समर्थन करते हैं: json, php और अचार) या तुरंत आपको आवश्यक विकल्पों के साथ Zend_Serializer वर्ग का एक उदाहरण।

उदाहरण:

Partcl:
$push = new pushBridge_IO( new pushBridge_Adapter_Partcl(Array('secretKey' => 'Your secret key')) );
पुशर:
$push = new pushBridge_IO( new pushBridge_Adapter_Pusher(Array('appId' => 'Your app Id', 'authKey' => 'Your key', 'secretKey' => 'Your secret key', 'debug' => true)) );
Pubnub:
$push = new pushBridge_IO( new pushBridge_Adapter_Pubnub(Array('readKey' => 'Your subscribe key', 'authKey' => 'Your publish key', 'secretKey' => ' Your secret key')) );
BeaconPush:
$push = new pushBridge_IO( new pushBridge_Adapter_Beaconpush(Array('authKey' => 'Your API Key', 'secretKey' => 'Your secret key')) );
और एक कस्टम धारावाहिक के साथ एक उदाहरण के रूप में:
$push = new pushBridge_IO( new pushBridge_Adapter_Partcl(Array('secretKey' => ' Your secret key')), 'php' );
या
$push = new pushBridge_IO( new pushBridge_Adapter_Partcl(Array('secretKey' => 'Your secret key')), Zend_Serializer::factory('Wddx', Array('comment' => 'Powered by ZF+pushBridge.IO') );

2. बस एक संदेश भेजें।

वास्तव में, सब कुछ इतना सरल नहीं है। मैसेजिंग के साथ सेवाएं बहुत अलग तरीके से काम करती हैं। सबसे सरल चैनल है-> संदेश मॉडल (या टैग -> संदेश), जबकि अन्य एक नए स्तर - चैनल -> घटना -> संदेश को पेश करते हैं। इसके अलावा, केवल अंश संदेश की सामग्री के प्रति बहुत सहिष्णु है, उसके लिए यह सिर्फ एक पंक्ति है, और इसकी समझ पूरी तरह से ग्राहक को हस्तांतरित की जाती है। दूसरों को जसन संरचनाओं में विशेष संदेश लपेटने की आवश्यकता होती है। कोई भी सेवा संदेशों के थोक भेजने का समर्थन नहीं करती है, जब एक अनुरोध में एक चैनल में विभिन्न चैनलों या कई अलग-अलग संदेशों और घटनाओं में डेटा प्रकाशित करना संभव होगा। हमने पहले ही इस क्षण को ध्यान में रखा है और हमारी Partcl.com सेवा के अगले संस्करण में ऐसा अवसर होगा, उसी समय इस कार्यक्षमता का एक अनुकरण सभी के लिए पुस्तकालय में दिखाई देगा (यह कहना उचित होगा कि इस तरह की कार्यक्षमता बीकोनपुश में कक्षा में लागू की जाती है, लेकिन मेरी लाइब्रेरी में पोर्ट नहीं की गई है) )।

सामान्य भेजने की विधि इस प्रकार है:

$push->send( '', 'channel', 'config' );

एक पहले से ही परिवर्तित स्ट्रिंग एडेप्टर विधि में मिलती है, इसलिए इसे डेटा प्राप्त करने की गारंटी दी जाती है और यह खाली स्ट्रिंग की तुलना में कुछ अधिक है। हालाँकि, यदि सेवा को इसकी आवश्यकता है, तो एडेप्टर संदेश डेटा के शीर्ष पर आवश्यक Json संरचना बनाएगा।

यदि सेवा चैनलों का उपयोग करती है, तो दूसरा पैरामीटर चैनलों का स्ट्रिंग (या सरणी) है जहां संदेश भेजा जाना चाहिए। यदि कोई चैनल नहीं है, तो यह एक टैग आईडी या अन्य आईडी है।

यदि आपको इवेंट कोड सेट करने की आवश्यकता है, तो कॉन्फ़िगरेशन का उपयोग करें - तीसरा पैरामीटर हमेशा एक सरणी है। ईवेंट इवेंट पैरामीटर में सेट है। इसके अतिरिक्त, आप पैरामीटर serialize = false पास करके क्रमांकन अक्षम कर सकते हैं। यदि सेवा स्वीकार करती है, तो आप अतिरिक्त संदेश पैरामीटर निर्दिष्ट कर सकते हैं, उदाहरण के लिए, पुशर में संदेशों के लिए X-Stream.ly या डीबग मोड सक्षम / अक्षम करें।

एक सरल संदेश भेजने का एक उदाहरण:

Partcl:
$push->send('Hello world from pushBridge.IO', 'Your tag id', Array('serialize' => false));
पुशर:
$push->send('Hello world from pushBridge.IO', 'test_channel', Array('serialize' => false, 'event' => 'push_test', 'debug' => true));
Pubnub:
$push->send('Hello world from pushBridge.IO', 'my_channel');
x-Stream.ly:
$push->send('Hello world from pushBridge.IO', 'mychannel', Array('event' => 'my_event', 'persisted' => true));

बेशक, डिफ़ॉल्ट रूप से, अधिकतम पैरामीटर सेट किए जाते हैं ताकि कुछ सेट करने की आवश्यकता न हो, अक्सर यहां तक ​​कि चैनल या इवेंट का नाम भी सेट किया जाता है क्योंकि वे पंजीकरण के बाद सेवा द्वारा असाइन किए जाते हैं। लेकिन विकल्पों की अधिक संपूर्ण समझ के लिए, आपको किसी विशेष सेवा के लिए प्रलेखन का उल्लेख करना चाहिए।


पुस्तकालय स्रोत कोड और संक्षिप्त उदाहरण: github.com/aleksraiden/pushBridge.IO/tree/ServiceWrapper

अगली रिलीज़ की योजना में बग फिक्सिंग, सेंड मेथड का एकीकरण, एक साथ कई वेरिएबल्स को प्रकाशित करने का समर्थन, डेटा रीडिंग मेथड का कार्यान्वयन और पुशक्लाउडैप डॉट कॉम डोमेन पर प्रोजेक्ट वेबसाइट को शामिल करना शामिल है। मैं टिप्पणियों और परिवर्धन के लिए आभारी रहूंगा।