काॅमेट प्रोग्रामिंग: Difference between revisions

From Vigyanwiki
No edit summary
No edit summary
Line 1: Line 1:
{{short description|Web application model}}
{{short description|Web application model}}
धूमकेतु [[वेब अनुप्रयोग]] मॉडल है जिसमें लंबे समय से आयोजित [[HTTPS]] अनुरोध [[वेब सर्वर]] को [[वेब ब्राउज़र]] के लिए तकनीकी डेटा पुश करने की अनुमति देता है, बिना ब्राउज़र के स्पष्ट रूप से अनुरोध किए।<ref name='MASH'>{{cite web | url = http://www.infoworld.com/d/developer-world/ajax-alliance-recognizes-mashups-559 | title = AJAX गठबंधन मैशअप को पहचानता है| access-date = 2010-10-20 | last = Krill | first = Paul | date = September 24, 2007 | publisher = [[InfoWorld]]}}</ref><ref name="CRANG">{{cite book|title=Comet and Reverse Ajax: The Next-Generation Ajax 2.0|last2=McCarthy|first2=Phil|date=October 13, 2008|publisher=[[Apress]]|isbn=978-1-59059-998-3|last1=Crane|first1=Dave}}<!--| accessdate = 2010-10-20 --></ref> धूमकेतु छत्र शब्द है, जिसमें इस अंतःक्रिया को प्राप्त करने के लिए कई तकनीकों को शामिल किया गया है। ये सभी विधियाँ गैर-डिफ़ॉल्ट प्लगइन्स के बजाय ब्राउज़रों में डिफ़ॉल्ट रूप से शामिल सुविधाओं पर निर्भर करती हैं, जैसे कि [[जावास्क्रिप्ट]]। धूमकेतु का दृष्टिकोण वर्ल्ड वाइड वेब#फंक्शन से भिन्न है, जिसमें ब्राउज़र समय में पूर्ण वेब पेज का अनुरोध करता है।<ref name = "WRC" />
'''काॅमेट प्रोग्रामिंग''' [[वेब अनुप्रयोग]] ऐसा प्रारूप है जिसमें लंबे समय से आयोजित होने वाले [[HTTPS|एचटीटीपीS]] पेज को [[वेब सर्वर]] द्वारा विभिन्न [[वेब ब्राउज़र]] के लिए तकनीकी रूप से डेटा को पुश करने की अनुमति देता है, इसके बिना ब्राउज़र को स्पष्ट रूप से अनुरोध किया जाता हैं।<ref name='MASH'>{{cite web | url = http://www.infoworld.com/d/developer-world/ajax-alliance-recognizes-mashups-559 | title = AJAX गठबंधन मैशअप को पहचानता है| access-date = 2010-10-20 | last = Krill | first = Paul | date = September 24, 2007 | publisher = [[InfoWorld]]}}</ref><ref name="CRANG">{{cite book|title=Comet and Reverse Ajax: The Next-Generation Ajax 2.0|last2=McCarthy|first2=Phil|date=October 13, 2008|publisher=[[Apress]]|isbn=978-1-59059-998-3|last1=Crane|first1=Dave}}<!--| accessdate = 2010-10-20 --></ref> काॅमेट ऐसा शब्द है, जिसमें इस अंतःक्रिया को प्राप्त करने के लिए कई तकनीकों को सम्मिलित किया गया है। ये सभी विधियाँ गैर-डिफ़ॉल्ट प्लगइन्स के अतिरिक्त ब्राउज़रों में डिफ़ॉल्ट रूप से सम्मिलित सुविधाओं पर निर्भर करती हैं, जैसे कि [[जावास्क्रिप्ट]] इसका उत्तम उदाहरण हैं। इस प्रकार काॅमेट का दृष्टिकोण वर्ल्ड वाइड वेब फंक्शन से भिन्न है, जिसमें ब्राउज़र समय में पूर्ण वेब पेज का अनुरोध करता है।<ref name = "WRC" />


[[वेब विकास]] में धूमकेतु तकनीकों का उपयोग सामूहिक तकनीकों के लिए निओलिज़्म के रूप में धूमकेतु शब्द के उपयोग से पहले का है। धूमकेतु सहित कई अन्य नामों से जाना जाता है
[[वेब विकास]] में काॅमेट तकनीकों का उपयोग सामूहिक तकनीकों के लिए निओलिज़्म के रूप में काॅमेट शब्द के उपयोग से पहले का है। इस प्रकार काॅमेट सहित कई अन्य नामों जैसे अजाक्स पुश,<ref>{{cite speech
अजाक्स पुश,<ref>{{cite speech
  | title = Ajax Push (a.k.a. Comet) with Java Business Integration (JBI)
  | title = Ajax Push (a.k.a. Comet) with Java Business Integration (JBI)
  | first = Andreas
  | first = Andreas
Line 17: Line 16:
|publisher=ICEfaces.org
|publisher=ICEfaces.org
| access-date = 2014-10-23
| access-date = 2014-10-23
}}</ref>
}}</ref> रिवर्स अजाक्स,<ref>{{cite book
रिवर्स अजाक्स,<ref>{{cite book
|title = Comet and Reverse Ajax: The Next Generation Ajax 2.0
|title = Comet and Reverse Ajax: The Next Generation Ajax 2.0
|first = Dave
|first = Dave
Line 26: Line 24:
|isbn = 1-59059-998-5
|isbn = 1-59059-998-5
|date=July 2008
|date=July 2008
}}</ref> टू-वे-वेब,<ref name="ajax-dp-oreilly"/>HTTP स्ट्रीमिंग,<ref name="ajax-dp-oreilly">{{cite book
}}</ref> टू-वे-वेब,<ref name="ajax-dp-oreilly">{{cite book
|title=Ajax Design Patterns
|title=Ajax Design Patterns
|first=Michael
|first=Michael
Line 37: Line 35:
|url-access=registration
|url-access=registration
|url=https://archive.org/details/ajaxdesignpatter00mahe/page/19
|url=https://archive.org/details/ajaxdesignpatter00mahe/page/19
}}</ref> और
}}</ref> एचटीटीपी स्ट्रीमिंग,<ref name="ajax-dp-oreilly" /> और [[HTTP पुश|एचटीटीपी पुश]]<ref>{{cite web
[[HTTP पुश]]<ref>{{cite web
|url = http://www.bluishcoder.co.nz/2005/11/more-on-ajax-and-server-push.html
|url = http://www.bluishcoder.co.nz/2005/11/more-on-ajax-and-server-push.html
|title = More on Ajax and server push
|title = More on Ajax and server push
Line 47: Line 44:
|access-date = 2008-05-05
|access-date = 2008-05-05
}}
}}
</ref>
</ref> से जाना जाता है।<ref>{{cite web
दूसरों के बीच में।<ref>{{cite web
  |url        = http://www.obviously.com/tech_tips/slow_load_technique
  |url        = http://www.obviously.com/tech_tips/slow_load_technique
  |title      = The Slow Load Technique/Reverse AJAX
  |title      = The Slow Load Technique/Reverse AJAX
Line 60: Line 56:
  |archive-date = 2006-02-08
  |archive-date = 2006-02-08
}}
}}
</ref> कॉमेट शब्द संक्षिप्त शब्द नहीं है, लेकिन एलेक्स रसेल ने अपने 2006 के [[ब्लॉग]] पोस्ट कॉमेट: लो लेटेंसी डेटा फॉर द ब्राउजर में गढ़ा था।<ref>{{cite web
</ref> इस प्रकार कॉमेट शब्द संक्षिप्त शब्द नहीं है, अपितु एलेक्स रसेल ने अपने 2006 के [[ब्लॉग]] पोस्ट कॉमेट: लो लेटेंसी डेटा फॉर द ब्राउजर में बनाया गया था।<ref>{{cite web
|url = http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/
|url = http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/
|title = Comet: Low Latency Data for the Browser
|title = Comet: Low Latency Data for the Browser
Line 68: Line 64:
|access-date = 2014-11-02
|access-date = 2014-11-02
}}
}}
</ref>
</ref> वर्तमान समय के कुछ वर्षों में, [[वेबसॉकेट]] और सर्वर-भेजे गए कार्यक्रमों के मानकीकरण और व्यापक समर्थन ने काॅमेट प्रारूप को अप्रचलित कर दिया है।
हाल के वर्षों में, [[वेबसॉकेट]] और सर्वर-भेजे गए कार्यक्रमों के मानकीकरण और व्यापक समर्थन ने धूमकेतु मॉडल को अप्रचलित कर दिया है।


== इतिहास ==
== इतिहास ==


=== शुरुआती [[जावा एप्लेट]]्स ===
=== प्रारंभिक [[जावा एप्लेट|जावा एप्लेट्स]] ===
जावा एप्लेट्स को ब्राउज़रों में एम्बेड करने की क्षमता (मार्च 1996 में [[नेटस्केप नेविगेटर 2]].0 के साथ शुरू)<ref>{{cite web |url=http://www27.netscape.com/comprod/products/navigator/version_2.0/index.html |title=नेटस्केप.कॉम|access-date=2017-08-16 |url-status=bot: unknown |archive-url=https://web.archive.org/web/19961115203505/http://www27.netscape.com/comprod/products/navigator/version_2.0/index.html |archive-date=November 15, 1996 }}</ref>) कच्चे [[ प्रसारण नियंत्रण प्रोटोकॉल |प्रसारण नियंत्रण प्रोटोकॉल]] सॉकेट का उपयोग करके दो-तरफ़ा निरंतर संचार को संभव बनाया<ref>[http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html "java.net.Socket (Java 2 Platform SE v1.4.2)"] {{webarchive |url=https://web.archive.org/web/20090519063251/http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html |date=May 19, 2009 }}</ref> ब्राउज़र और सर्वर के बीच संचार करने के लिए। यह सॉकेट तब तक खुला रह सकता है जब तक ब्राउज़र एप्लेट को होस्ट करने वाले दस्तावेज़ पर है। ईवेंट सूचनाएं किसी भी प्रारूप में भेजी जा सकती हैं{{snd}} टेक्स्ट या बाइनरी{{snd}} और एप्लेट द्वारा डिकोड किया गया।
जावा एप्लेट्स को ब्राउज़रों में एम्बेड करने की क्षमता के अनुसार मार्च 1996 में [[नेटस्केप नेविगेटर 2]].0 के साथ प्रारंभ किया गया था।<ref>{{cite web |url=http://www27.netscape.com/comprod/products/navigator/version_2.0/index.html |title=नेटस्केप.कॉम|access-date=2017-08-16 |url-status=bot: unknown |archive-url=https://web.archive.org/web/19961115203505/http://www27.netscape.com/comprod/products/navigator/version_2.0/index.html |archive-date=November 15, 1996 }}</ref> जिसके द्वारा प्रारंभिक [[ प्रसारण नियंत्रण प्रोटोकॉल |प्रसारण नियंत्रण प्रोटोकॉल]] के लिए सॉकेट का उपयोग करके दोनो दिशाओं से निरंतर संचार को संभव बनाया गया था,<ref>[http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html "java.net.Socket (Java 2 Platform SE v1.4.2)"] {{webarchive |url=https://web.archive.org/web/20090519063251/http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html |date=May 19, 2009 }}</ref> इस प्रकार ब्राउज़र और सर्वर के बीच संचार करने के लिए इसका उपयोग किया जाता हैं। यह सॉकेट तब तक ओपेन रह सकता है जब ब्राउज़र एप्लेट को होस्ट करने वाले डाक्यूमेंट पर उपलब्ध रहते हैं। इसके अतिरिक्त ईवेंट सूचनाएं किसी भी प्रारूप में भेजी जा सकती हैं, इसके अनुसार टेक्स्ट या बाइनरी और एप्लेट द्वारा डिकोड किया गया हैं।


=== पहला ब्राउज़र-टू-ब्राउज़र संचार ढांचा ===
=== सर्वप्रथम ब्राउज़र-टू-ब्राउज़र संचार प्रारूप ===
ब्राउज़र-टू-ब्राउज़र संचार का उपयोग करने वाला पहला एप्लिकेशन टैंगो इंटरएक्टिव था,<ref>{{Cite web
ब्राउज़र-टू-ब्राउज़र संचार का उपयोग करने वाला पहला एप्लिकेशन टैंगो इंटरएक्टिव था,<ref>{{Cite web
| url = http://surface.syr.edu/cgi/viewcontent.cgi?article=1076&context=npac
| url = http://surface.syr.edu/cgi/viewcontent.cgi?article=1076&context=npac
Line 86: Line 81:
| publisher = Northeast Parallel Architecture Center, College of Engineering and Computer Science
| publisher = Northeast Parallel Architecture Center, College of Engineering and Computer Science
| access-date = 27 February 2016
| access-date = 27 February 2016
}}</ref> 1996-98 में नॉर्थईस्ट पैरेलल आर्किटेक्चर सेंटर ([http://surface.syr.edu/npac/ NPAC]) में [[सिराकस यूनिवर्सिटी]] में [[DARPA]] फंडिंग का उपयोग करके लागू किया गया। टैंगो वास्तुकला को सिरैक्यूज़ विश्वविद्यालय द्वारा पेटेंट कराया गया है।<ref>{{Citation|last = Podgorny|first = Marek|title = United States Patent: 6078948 - Platform-independent collaboration backbone and framework for forming virtual communities having virtual rooms with collaborative sessions|date = June 20, 2000|url = http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%252Fnetahtml%252FPTO%252Fsearch-bool.html&r=14&f=G&l=50&co1=AND&d=PTXT&s1=Podgorny.INNM.&OS=IN/Podgorny&RS=IN/Podgorny|last2 = Beca|last3 = Cheng|last4 = Fox|last5 = Jurga|last6 = Olszewski|last7 = Sokolowski|last8 = Walczak|last9 = PL|first2 = Lukasz|first3 = Gang|first4 = Geoffrey C.|first5 = Tomasz|first6 = Konrad|first7 = Piotr|first8 = Krzysztof|access-date = 2016-02-27}}</ref> दूरस्थ शिक्षा उपकरण के रूप में टैंगो ढांचे का बड़े पैमाने पर उपयोग किया गया है।<ref>{{Cite web
}}</ref> इस प्रकार 1996-98 में नॉर्थईस्ट पैरेलल आर्किटेक्चर सेंटर ([http://surface.syr.edu/npac/ एनपीएसी]) में [[सिराकस यूनिवर्सिटी]] में [[DARPA|डार्पा]] फंडिंग का उपयोग करके लागू किया गया था। इसके अनुसार टैंगो संरचना को सिरैक्यूज़ विश्वविद्यालय द्वारा पेटेंट कराया गया है।<ref>{{Citation|last = Podgorny|first = Marek|title = United States Patent: 6078948 - Platform-independent collaboration backbone and framework for forming virtual communities having virtual rooms with collaborative sessions|date = June 20, 2000|url = http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%252Fnetahtml%252FPTO%252Fsearch-bool.html&r=14&f=G&l=50&co1=AND&d=PTXT&s1=Podgorny.INNM.&OS=IN/Podgorny&RS=IN/Podgorny|last2 = Beca|last3 = Cheng|last4 = Fox|last5 = Jurga|last6 = Olszewski|last7 = Sokolowski|last8 = Walczak|last9 = PL|first2 = Lukasz|first3 = Gang|first4 = Geoffrey C.|first5 = Tomasz|first6 = Konrad|first7 = Piotr|first8 = Krzysztof|access-date = 2016-02-27}}</ref> इस प्रकार दूरस्थ शिक्षा उपकरण के रूप में टैंगो प्रारूप का बड़े पैमाने पर उपयोग किया गया है।<ref>{{Cite web
| url = https://www.dsc.soic.indiana.edu/sites/default/files/tr_9921.pdf
| url = https://www.dsc.soic.indiana.edu/sites/default/files/tr_9921.pdf
| title = Experiences with Using TANGO Interactive in a Distributed Workshop
| title = Experiences with Using TANGO Interactive in a Distributed Workshop
Line 95: Line 90:
| publisher = CEWES MSRC/PET TR/99-21
| publisher = CEWES MSRC/PET TR/99-21
| access-date = 27 February 2016
| access-date = 27 February 2016
}}</ref> [http://www.collabworx.com CollabWorx] द्वारा इस ढांचे का व्यावसायीकरण किया गया है और संयुक्त राज्य अमेरिका के रक्षा विभाग में दर्जन या इतने ही कमान और नियंत्रण और प्रशिक्षण अनुप्रयोगों में उपयोग किया गया है।.
}}</ref> [http://www.collabworx.com कोलैब वर्क्स] द्वारा इस प्रारूप का व्यावसायीकरण किया गया है और संयुक्त राज्य अमेरिका के रक्षा विभाग में दर्जन या इतने ही कमान और नियंत्रण और प्रशिक्षण अनुप्रयोगों में उपयोग किया गया है।.


=== पहला धूमकेतु अनुप्रयोग ===
=== सर्वप्रथम काॅमेट अनुप्रयोग ===
धूमकेतु कार्यान्वयन का पहला सेट 2000 से पहले का है,<ref name="CometDaily_History">{{cite web |url=http://cometdaily.com/2007/10/19/comet-and-push-technology/ |title=धूमकेतु दैनिक: धूमकेतु और धक्का प्रौद्योगिकी|access-date=2007-12-15 |archive-url=https://web.archive.org/web/20071113174053/http://cometdaily.com/2007/10/19/comet-and-push-technology/ |archive-date=2007-11-13 |url-status=dead }}</ref> [[Pushlets]], [[Lightstreamer]], और KnowNow परियोजनाओं के साथ। Pushlets, Just van den Broecke द्वारा बनाया गया ढांचा, सबसे पहले में से था<ref name="pushlets-javaworld">Just van den Broecke (1 March 2000). “[http://www.javaworld.com/article/2076063/java-web-development/pushlets--send-events-from-servlets-to-dhtml-client-browsers.html Pushlets: Send events from servlets to DHTML client browsers]”. JavaWorld. Retrieved 1 August 2014.</ref> खुला स्रोत कार्यान्वयन। पुशलेट सर्वर-साइड जावा सर्वलेट्स और क्लाइंट-साइड जावास्क्रिप्ट लाइब्रेरी पर आधारित थे। बैंग नेटवर्क{{snd}} [[नेटस्केप]] के सह-संस्थापक [[मार्क आंद्रेसेन]] द्वारा समर्थित [[सिलिकॉन वैली]] स्टार्ट-अप{{snd}} के पास संपूर्ण वेब के लिए रीयल-टाइम पुश मानक बनाने का भरपूर वित्तपोषित प्रयास था।<ref>{{cite web
काॅमेट कार्यान्वयन का पहला सेट 2000 से पहले का है,<ref name="CometDaily_History">{{cite web |url=http://cometdaily.com/2007/10/19/comet-and-push-technology/ |title=धूमकेतु दैनिक: धूमकेतु और धक्का प्रौद्योगिकी|access-date=2007-12-15 |archive-url=https://web.archive.org/web/20071113174053/http://cometdaily.com/2007/10/19/comet-and-push-technology/ |archive-date=2007-11-13 |url-status=dead }}</ref> जिसे [[Pushlets|पुशलेट्स]], [[Lightstreamer|लाइट स्ट्रीमर]], और नो नाओ परियोजनाओं के साथ प्रदर्शित किया गया था। इस प्रकार पुशलेट्स, जस्ट वैन डेन ब्रौएके द्वारा बनाया गया प्रारूप सबसे पहले उपयोग किया गया था<ref name="pushlets-javaworld">Just van den Broecke (1 March 2000). “[http://www.javaworld.com/article/2076063/java-web-development/pushlets--send-events-from-servlets-to-dhtml-client-browsers.html Pushlets: Send events from servlets to DHTML client browsers]”. JavaWorld. Retrieved 1 August 2014.</ref> इस प्रकार ओपेन स्रोत कार्यान्वयन के लिए पुशलेट सर्वर-साइड जावा सर्वलेट्स और क्लाइंट-साइड जावास्क्रिप्ट लाइब्रेरी पर आधारित थे। जिसके कारण बैंग नेटवर्क{{snd}} [[नेटस्केप]] के सह-संस्थापक [[मार्क आंद्रेसेन]] द्वारा समर्थित [[सिलिकॉन वैली]] स्टार्ट-अप के पास संपूर्ण वेब के लिए रीयल-टाइम पुश मानक बनाने का भरपूर वित्तपोषित प्रयास था।<ref>{{cite web
|url=http://news.cnet.com/2100-1023-255088.html
|url=http://news.cnet.com/2100-1023-255088.html
|title=Will the "refresh" button become obsolete?
|title=Will the "refresh" button become obsolete?
Line 106: Line 101:
|publisher=[[CNET Networks]]
|publisher=[[CNET Networks]]
|access-date=2008-07-22
|access-date=2008-07-22
}}</ref>
}}</ref> इस प्रकार अप्रैल 2001 में, चिप मॉर्निंगस्टार ने जावा-आधारित (J2SE) वेब सर्वर विकसित करना प्रारंभ कर दिया था, जो इसके परिणामस्वरूप दो एचटीटीपी सॉकेट का उपयोग करने में सक्षम थे, इसके द्वारा डिज़ाइन किए गए कस्टम एचटीटीपी सर्वर और [[डगलस क्रॉकफोर्ड]] द्वारा डिज़ाइन किए गए क्लाइंट के बीच दो संचार चैनलों को ओपेन रखता था, जून 2001 तक कार्यशील डेमो सिस्टम अस्तित्व में आया था। जिसके परिणामस्वरूप सर्वर और क्लाइंट ने मैसेजिंग प्रारूप का उपयोग किया जिसे क्रॉकफोर्ड के सुझाव के बाद स्टेट सॉफ्टवेयर, इंक. के संस्थापकों ने [[JSON|जेसाॅन]] के रूप में बनाने के लिए सहमति दी थी। इस प्रकार संपूर्ण सिस्टम, क्लाइंट लाइब्रेरी, मैसेजिंग फॉर्मेट जिसे जेसाॅन और सर्वर के रूप में जाना जाता है, स्टेट एप्लिकेशन फ्रेमवर्क बन गया, जिसके कुछ भागों को सन माइक्रोसिस्टम, Amazon.com, ईडीएस और वोक्सवैगेन द्वारा बेचा और उपयोग किया गया था।
अप्रैल 2001 में, चिप मॉर्निंगस्टार ने जावा-आधारित (J2SE) वेब सर्वर विकसित करना शुरू किया, जो दो HTTP सॉकेट का उपयोग करता था, जो उनके द्वारा डिज़ाइन किए गए कस्टम HTTP सर्वर और [[डगलस क्रॉकफोर्ड]] द्वारा डिज़ाइन किए गए क्लाइंट के बीच दो संचार चैनलों को खुला रखता था; जून 2001 तक कार्यशील डेमो सिस्टम अस्तित्व में था। सर्वर और क्लाइंट ने मैसेजिंग प्रारूप का उपयोग किया जिसे क्रॉकफोर्ड के सुझाव के बाद स्टेट सॉफ्टवेयर, इंक. के संस्थापकों ने [[JSON]] के रूप में बनाने के लिए सहमति दी। संपूर्ण सिस्टम, क्लाइंट लाइब्रेरी, मैसेजिंग फॉर्मेट जिसे JSON और सर्वर के रूप में जाना जाता है, स्टेट एप्लिकेशन फ्रेमवर्क बन गया, जिसके कुछ हिस्सों को Sun Microsystems, Amazon.com, EDS और Volkswagen द्वारा बेचा और इस्तेमाल किया गया।


मार्च 2006 में, [[सॉफ्टवेयर इंजीनियर]] एलेक्स रसेल ने अपने निजी ब्लॉग पर पोस्ट में धूमकेतु शब्द गढ़ा।<ref name="alex_comet">एलेक्स रसेल (3 मार्च 2006)। "[http://alex.dojotoolkit.org/?p=545 धूमकेतु: ब्राउज़र के लिए कम विलंबता डेटा] {{Webarchive|url=https://web.archive.org/web/20080812034003/http://alex.dojotoolkit.org/?p=545 |date=2008-08-12 }}”। एलेक्स रसेल का ब्लॉग। 29 नवंबर 2007 को पुनःप्राप्त। </ref> नया शब्द [[अजाक्स (प्रोग्रामिंग)]] ([[अजाक्स (क्लीन्ज़र)]] और [[धूमकेतु (क्लीन्ज़र)]] दोनों संयुक्त राज्य अमेरिका में आम घरेलू क्लीनर होने पर नाटक था)। रेफरी>{{cite web
मार्च 2006 में, [[सॉफ्टवेयर इंजीनियर]] एलेक्स रसेल ने अपने निजी ब्लॉग पर पोस्ट में काॅमेट शब्द को चयनित किया।<ref name="alex_comet">एलेक्स रसेल (3 मार्च 2006)। "[http://alex.dojotoolkit.org/?p=545 धूमकेतु: ब्राउज़र के लिए कम विलंबता डेटा] {{Webarchive|url=https://web.archive.org/web/20080812034003/http://alex.dojotoolkit.org/?p=545 |date=2008-08-12 }}”। एलेक्स रसेल का ब्लॉग। 29 नवंबर 2007 को पुनःप्राप्त। </ref> इस नये शब्द [[अजाक्स (प्रोग्रामिंग)]] [[अजाक्स (क्लीन्ज़र)]] और [[धूमकेतु (क्लीन्ज़र)|काॅमेट (क्लीन्ज़र)]] दोनों संयुक्त राज्य अमेरिका में आम घरेलू क्लीनर होने पर प्रदर्शित होता था। <ref>{{cite web
|url=http://www.eweek.com/c/a/Application-Development/Microsoft-Scrubs-Comet-from-AJAX-Tool-Set/
|url=http://www.eweek.com/c/a/Application-Development/Microsoft-Scrubs-Comet-from-AJAX-Tool-Set/
|title=Microsoft ने AJAX टूल सेट से धूमकेतु को स्क्रब किया|last=K. Taft
|title=Microsoft ने AJAX टूल सेट से धूमकेतु को स्क्रब किया|last=K. Taft
Line 117: Line 111:
|access-date=2008-07-21
|access-date=2008-07-21
}}</ref><ref>[http://en.oreilly.com/oscon2008/public/schedule/detail/3048 Orbited: Enabling Comet for the Masses: OSCON 2008 - O'Reilly Conferences, July 21 - 25, 2008, Portland, Oregon<!-- Bot generated title -->]</ref><ref>[http://www.web2journal.com/read/457966.htm Enterprise Comet & Web 2.0 Live Presentation<!-- Bot generated title -->] {{webarchive|url=https://web.archive.org/web/20080520222527/http://www.web2journal.com/read/457966.htm |date=2008-05-20 }}</ref>
}}</ref><ref>[http://en.oreilly.com/oscon2008/public/schedule/detail/3048 Orbited: Enabling Comet for the Masses: OSCON 2008 - O'Reilly Conferences, July 21 - 25, 2008, Portland, Oregon<!-- Bot generated title -->]</ref><ref>[http://www.web2journal.com/read/457966.htm Enterprise Comet & Web 2.0 Live Presentation<!-- Bot generated title -->] {{webarchive|url=https://web.archive.org/web/20080520222527/http://www.web2journal.com/read/457966.htm |date=2008-05-20 }}</ref>
2006 में, कुछ अनुप्रयोगों ने उन तकनीकों को व्यापक दर्शकों के सामने उजागर किया: [[मीबो]] के बहु-प्रोटोकॉल वेब-आधारित चैट एप्लिकेशन ने उपयोगकर्ताओं को [[एओएल इंस्टेंट मैसेंजर]], याहू! ब्राउज़र के माध्यम से मैसेंजर, और [[एमएसएन मैसेंजर]] चैट प्लेटफॉर्म; Google ने [[ जीमेल लगीं |जीमेल लगीं]] में वेब-आधारित चैट जोड़ी; [[JotSpot]], Google द्वारा अधिग्रहित होने के बाद से स्टार्टअप, ने धूमकेतु-आधारित वास्तविक समय सहयोगी दस्तावेज़ संपादन का निर्माण किया।<ref>Dion Almaer (29 September 2005). “[http://ajaxian.com/archives/jotspot-live-live-group-note-taking Jotspot Live: Live, group note-taking]” (interview with Abe Fettig). Ajaxian. Retrieved 15 December 2007. <br>Matt Marshall (15 December 2006). “[https://venturebeat.com/2006/12/15/renkoo-launches-just-in-time-to-schedule-holiday-cocktails/ Renkoo launches event service — in time to schedule holiday cocktails]”. Venture Beat. Retrieved 15 December 2007.</ref> नए धूमकेतु वेरिएंट बनाए गए थे, जैसे कि जावा-आधारित [[ICEfaces]] [[JavaServer Faces]] फ्रेमवर्क (हालांकि वे अजाक्स पुश शब्द को पसंद करते हैं)<ref name="ice"/>). अन्य जो पहले जावा-एप्लेट आधारित ट्रांसपोर्ट का इस्तेमाल करते थे, शुद्ध-जावास्क्रिप्ट कार्यान्वयन के बजाय स्विच किए गए थे।<ref>Clint Boulton (27 December 2005). “[http://www.devxnews.com/article.php/3573506/ Startups Board the AJAX Bandwagon]”. DevX News. Retrieved 18 February 2008.</ref>
 
2006 में, कुछ अनुप्रयोगों ने उन तकनीकों को व्यापक दर्शकों के सामने प्रस्तुत किया था: [[मीबो]] के बहु-प्रोटोकॉल वेब-आधारित चैट एप्लिकेशन ने उपयोगकर्ताओं को [[एओएल इंस्टेंट मैसेंजर]], याहू! ब्राउज़र के माध्यम से मैसेंजर, और [[एमएसएन मैसेंजर]] चैट प्लेटफॉर्म, गूगल ने [[ जीमेल लगीं |जीमेल लगीं]] में वेब-आधारित चैट को जोड़ा, [[JotSpot|जाॅट स्पाट]], गूगल द्वारा अधिग्रहित होने के बाद से स्टार्टअप, ने काॅमेट-आधारित वास्तविक समय सहयोगी डाॅक्यूमेंट के संपादन का निर्माण किया था।<ref>Dion Almaer (29 September 2005). “[http://ajaxian.com/archives/jotspot-live-live-group-note-taking Jotspot Live: Live, group note-taking]” (interview with Abe Fettig). Ajaxian. Retrieved 15 December 2007. <br>Matt Marshall (15 December 2006). “[https://venturebeat.com/2006/12/15/renkoo-launches-just-in-time-to-schedule-holiday-cocktails/ Renkoo launches event service — in time to schedule holiday cocktails]”. Venture Beat. Retrieved 15 December 2007.</ref> इस प्रकार से प्राप्त नए काॅमेट वेरिएंट बनाए गए थे, जैसे कि जावा-आधारित [[ICEfaces|आईसीई फेसेज]] [[JavaServer Faces|जावा सर्वर फेसेज]] फ्रेमवर्क हैं, चूंकि इस प्रकार अजाक्स पुश शब्द को उपयोग करते हैं,<ref name="ice" /> इस प्रकार के अन्य पहले के जावा-एप्लेट आधारित ट्रांसपोर्ट का उपयोग करते थे, जो मुख्य रूप से शुद्ध-जावास्क्रिप्ट कार्यान्वयन के अतिरिक्त स्विच किए गए थे।<ref>Clint Boulton (27 December 2005). “[http://www.devxnews.com/article.php/3573506/ Startups Board the AJAX Bandwagon]”. DevX News. Retrieved 18 February 2008.</ref>
== कार्यान्वयन ==
== कार्यान्वयन ==
धूमकेतु अनुप्रयोग वर्ल्ड वाइड वेब # फंक्शन | पृष्ठ-दर-पृष्ठ वेब मॉडल और पारंपरिक [[मतदान (कंप्यूटर विज्ञान)]] की सीमाओं को समाप्त करने का प्रयास करते हैं, सर्वर और के बीच निरंतर या लंबे समय तक चलने वाले HTTP कनेक्शन का उपयोग करके दो-तरफा निरंतर बातचीत की पेशकश करते हैं। ग्राहक। चूंकि ब्राउज़र और प्रॉक्सी को सर्वर ईवेंट को ध्यान में रखकर नहीं बनाया गया है, इसलिए इसे हासिल करने के लिए कई तकनीकें विकसित की गई हैं, जिनमें से प्रत्येक के अलग-अलग लाभ और कमियां हैं। सबसे बड़ी बाधा [[ हाइपरटेक्स्ट परहस्त शिष्टाचार |हाइपरटेक्स्ट परहस्त शिष्टाचार]] 1.1 विनिर्देश है, जो इस विनिर्देश को बताता है... ग्राहकों को कई कनेक्शन खोलते समय रूढ़िवादी होने के लिए प्रोत्साहित करता है।<ref>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, [http://tools.ietf.org/html/rfc7230#section-6.4 section 6.4]. IETF. Retrieved 2014-07-29</ref> इसलिए, वास्तविक समय की घटनाओं के लिए कनेक्शन खुला रखने से ब्राउज़र की उपयोगिता पर नकारात्मक प्रभाव पड़ता है: पिछले अनुरोध के परिणामों की प्रतीक्षा करते समय ब्राउज़र को नया अनुरोध भेजने से रोका जा सकता है, उदाहरण के लिए, छवियों की श्रृंखला। वास्तविक समय की जानकारी के लिए अलग [[ होस्ट का नाम |होस्ट का नाम]] बनाकर इसे हल किया जा सकता है, जो ही भौतिक सर्वर के लिए उपनाम है। यह रणनीति डोमेन शार्डिंग का अनुप्रयोग है।
काॅमेट अनुप्रयोग वर्ल्ड वाइड वेब फंक्शन या पेज से पेज के लिए वेब प्रारूप और पारंपरिक [[मतदान (कंप्यूटर विज्ञान)|कंप्यूटर विज्ञान]] की सीमाओं को समाप्त करने का प्रयास करते हैं, सर्वर और के बीच निरंतर या लंबे समय तक चलने वाले एचटीटीपी कनेक्शन का उपयोग करके दो-तरफा निरंतर बातचीत की प्रस्तुत करते हैं। चूंकि इस प्रकार ब्राउज़र और प्रॉक्सी को सर्वर ईवेंट को ध्यान में रखकर नहीं बनाया गया है, इसलिए इसे प्राप्त करने के लिए कई तकनीकें विकसित की गई हैं, जिनमें से प्रत्येक के अलग-अलग लाभ और कमियां हैं। इस प्रकार इसकी सबसे बड़ी बाधा [[ हाइपरटेक्स्ट परहस्त शिष्टाचार |हाइपरटेक्स्ट]] से जुड़ी 1.1 विनिर्देश है, जो इस विनिर्देश को यह बताता है कि ग्राहकों को कई कनेक्शन ओपेन करते समय रूढ़िवादी होने के लिए प्रोत्साहित करता है।<ref>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, [http://tools.ietf.org/html/rfc7230#section-6.4 section 6.4]. IETF. Retrieved 2014-07-29</ref> इसलिए, वास्तविक समय की घटनाओं के लिए कनेक्शन ओपेन रखने से ब्राउज़र की उपयोगिता पर ऋणात्मक प्रभाव पड़ता है: पिछले अनुरोध के परिणामों की प्रतीक्षा करते समय ब्राउज़र को नया अनुरोध भेजने से रोका जा सकता है, उदाहरण के लिए इमेजेस की श्रृंखला इसका प्रमुख उदाहरण हैं। इस प्रकार वास्तविक समय की जानकारी के लिए अलग [[ होस्ट का नाम |होस्ट का नाम]] बनाकर इसे हल किया जा सकता है, जो भौतिक सर्वर के लिए उपनाम है। यह रणनीति डोमेन शार्डिंग का अनुप्रयोग है।


धूमकेतु को लागू करने के विशिष्ट तरीके दो प्रमुख श्रेणियों में आते हैं: स्ट्रीमिंग और [[ लंबा मतदान |लंबा मतदान]]
काॅमेट को लागू करने के विशिष्ट तरीके दो प्रमुख श्रेणियों स्ट्रीमिंग और [[ लंबा मतदान |लांग]] में आते हैं।


=== स्ट्रीमिंग ===
=== स्ट्रीमिंग ===
स्ट्रीमिंग धूमकेतु का उपयोग करने वाला एप्लिकेशन वेब ब्राउज़र से सभी कॉमेट [[ घटना (कंप्यूटिंग) |घटना (कंप्यूटिंग)]] के लिए सर्वर पर सतत कनेक्शन खोलता है। हर बार जब सर्वर नया ईवेंट भेजता है, तो इन घटनाओं को ग्राहक की ओर से नियंत्रित और व्याख्यायित किया जाता है, जिसमें कोई भी पक्ष कनेक्शन बंद नहीं करता है।<ref name = "WRC">{{cite web | url = http://www.webreference.com/programming/javascript/rg28/ | title = Comet Programming: Using Ajax to Simulate Server Push | access-date = 2010-10-20 | last = Gravelle | first = Rob | publisher = Webreference.com | archive-url = https://web.archive.org/web/20101018055530/http://www.webreference.com/programming/javascript/rg28/ | archive-date = 2010-10-18 | url-status = dead }}</ref>
'''स्ट्रीमिंग''' काॅमेट का उपयोग करने वाला एप्लिकेशन वेब ब्राउज़र से सभी कॉमेट [[ घटना (कंप्यूटिंग) |घटना (कंप्यूटिंग)]] के लिए सर्वर पर सतत कनेक्शन को ओपेन करता है। इस प्रकार निरंतर सर्वर के नये ईवेंट को भेजता है, तो इन घटनाओं को ग्राहक की ओर से नियंत्रित और व्याख्यायित किया जाता है, जिसमें कोई भी पक्ष कनेक्शन बंद नहीं करता है।<ref name = "WRC">{{cite web | url = http://www.webreference.com/programming/javascript/rg28/ | title = Comet Programming: Using Ajax to Simulate Server Push | access-date = 2010-10-20 | last = Gravelle | first = Rob | publisher = Webreference.com | archive-url = https://web.archive.org/web/20101018055530/http://www.webreference.com/programming/javascript/rg28/ | archive-date = 2010-10-18 | url-status = dead }}</ref>
स्ट्रीमिंग धूमकेतु को पूरा करने की विशिष्ट तकनीकों में निम्नलिखित शामिल हैं:
 
स्ट्रीमिंग काॅमेट को पूरा करने की विशिष्ट तकनीकों में निम्नलिखित सम्मिलित हैं:


==== हिडन आईफ्रेम ====
==== हिडन आईफ्रेम ====
डायनेमिक वेब एप्लिकेशन के लिए बुनियादी तकनीक छिपे हुए HTML तत्व # फ्रेम्स HTML तत्व (एक इनलाइन फ्रेम, जो वेबसाइट को HTML दस्तावेज़ को दूसरे के अंदर एम्बेड करने की अनुमति देता है) का उपयोग करना है। यह अदृश्य आईफ्रेम [[चुनकेड ट्रांसफर एन्कोडिंग]] ब्लॉक के रूप में भेजा जाता है, जो इसे असीमित रूप से लंबे समय तक घोषित करता है (कभी-कभी हमेशा के लिए फ्रेम कहा जाता है)। जैसे ही घटनाएं होती हैं, आईफ्रेम धीरे-धीरे भर जाता है <code>script</code> टैग, जिसमें ब्राउज़र में निष्पादित होने वाली जावास्क्रिप्ट शामिल है। क्योंकि ब्राउज़र HTML पृष्ठों को वृद्धिशील रूप से प्रस्तुत करते हैं, प्रत्येक <code>script</code> टैग प्राप्त होते ही निष्पादित किया जाता है। कुछ ब्राउज़रों को पार्सिंग और निष्पादन शुरू करने से पहले विशिष्ट न्यूनतम दस्तावेज़ आकार की आवश्यकता होती है, जिसे शुरू में 1-2 kB पैडिंग स्पेस भेजकर प्राप्त किया जा सकता है।<ref name="ajaxoreilly">{{cite book
डायनेमिक वेब एप्लिकेशन के लिए मौलिक तकनीक छिपे हुए एचटीएमएल एलिमेंट को फ्रेम्स एचटीएमएल एलिमेंट के लिए इनलाइन फ्रेम, जो वेबसाइट को एचटीएमएल डाक्यूमेंट को दूसरे के अंदर एम्बेड करने की अनुमति देता है जो इसका उपयोग करता है। इस प्रकार यह '''हिडेन आईफ्रेम''' [[चुनकेड ट्रांसफर एन्कोडिंग]] ब्लॉक के रूप में भेजा जाता है, जो इसे असीमित रूप से लंबे समय तक घोषित करता है, जो कभी-कभी या सदैव इसके लिए फ्रेम किया जाता है। जैसे ही इस प्रकार की घटनाएं होती हैं, जो इस प्रकार आईफ्रेम को धीरे-धीरे भर देता है, जिसके फलस्वरूप  <code>script</code> टैग, जिसमें ब्राउज़र में निष्पादित होने वाली जावास्क्रिप्ट सम्मिलित हो जाती है। क्योंकि ब्राउज़र एचटीएमएल पृष्ठों को वृद्धिशील रूप से प्रस्तुत करते हैं, प्रत्येक <code>script</code> टैग प्राप्त होते ही निष्पादित किया जाता है। कुछ ब्राउज़रों को पार्सिंग और निष्पादन प्रारंभ करने से पहले विशिष्ट न्यूनतम डाक्यूमेंट आकार की आवश्यकता होती है, जिसे प्रारंभ में 1-2 kB पैडिंग स्पेस भेजकर प्राप्त किया जा सकता है।<ref name="ajaxoreilly">{{cite book
  | last = Holdener III
  | last = Holdener III
  | first = Anthony T.  
  | first = Anthony T.  
Line 138: Line 134:
  | page = 320
  | page = 320
}}</ref>
}}</ref>
iframes पद्धति का लाभ यह है कि यह प्रत्येक सामान्य ब्राउज़र में काम करती है। इस तकनीक के दो डाउनसाइड विश्वसनीय त्रुटि प्रबंधन पद्धति की कमी है, और अनुरोध कॉलिंग प्रक्रिया की स्थिति को ट्रैक करने की असंभवता है।<ref name="ajaxoreilly"/>
==== [[XMLHttpRequest]] ====
XMLHttpRequest (XHR) ऑब्जेक्ट, ब्राउज़र-सर्वर संचार के लिए अजाक्स अनुप्रयोगों द्वारा उपयोग किया जाने वाला उपकरण, XHR प्रतिक्रिया के लिए कस्टम डेटा प्रारूप उत्पन्न करके और ब्राउज़र का उपयोग करके प्रत्येक ईवेंट को पार्स करके सर्वर-ब्राउज़र कॉमेट मैसेजिंग के लिए सेवा में दबाया जा सकता है साइड जावास्क्रिप्ट; केवल ब्राउज़र फायरिंग पर भरोसा करते हुए <code>onreadystatechange</code> कॉलबैक हर बार यह नया डेटा प्राप्त करता है।


=== लंबे मतदान के साथ अजाक्स ===
आई फ्रेम्स पद्धति का लाभ यह है कि यह प्रत्येक सामान्य ब्राउज़र में कार्य करती है। इस तकनीक के दो डाउनसाइड विश्वसनीय त्रुटि प्रबंधन पद्धति की कमी है, और इस प्रकार अनुरोध कॉलिंग प्रक्रिया की स्थिति को ट्रैक करने की असंभवता है।<ref name="ajaxoreilly" />
उपरोक्त स्ट्रीमिंग ट्रांसपोर्ट में से कोई भी नकारात्मक साइड-इफेक्ट के बिना सभी आधुनिक ब्राउज़रों में काम नहीं करता है। यह धूमकेतु डेवलपर्स को ब्राउज़र के आधार पर उनके बीच स्विच करने, कई जटिल स्ट्रीमिंग ट्रांसपोर्ट को लागू करने के लिए मजबूर करता है। नतीजतन, कई धूमकेतु अनुप्रयोग लंबे मतदान का उपयोग करते हैं, जो कि ब्राउज़र पक्ष पर लागू करना आसान है, और XHR का समर्थन करने वाले प्रत्येक ब्राउज़र में कम से कम काम करता है। जैसा कि नाम से पता चलता है, लंबे मतदान के लिए क्लाइंट को किसी ईवेंट (या ईवेंट के सेट) के लिए सर्वर को पोल करने की आवश्यकता होती है। ब्राउज़र सर्वर के लिए अजाक्स-शैली का अनुरोध करता है, जो तब तक खुला रहता है जब तक सर्वर के पास ब्राउज़र को भेजने के लिए नया डेटा नहीं होता है, जो ब्राउज़र को पूर्ण प्रतिक्रिया में भेजा जाता है। बाद की घटनाओं को प्राप्त करने के लिए ब्राउज़र नया लंबा मतदान अनुरोध शुरू करता है। [https://tools.ietf.org/html/rfc6202 IETF RFC 6202 लॉन्ग पोलिंग और द्विदिश HTTP में स्ट्रीमिंग के उपयोग के लिए ज्ञात मुद्दे और सर्वोत्तम अभ्यास] लंबे पोलिंग और HTTP स्ट्रीमिंग की तुलना करता है।
==== [[XMLHttpRequest|एक्सएमएल एचटीटीपी रिक्वेस्ट]] ====
लंबे मतदान को पूरा करने के लिए विशिष्ट तकनीकों में निम्नलिखित शामिल हैं:
'''एक्सएमएल एचटीटीपी रिक्वेस्ट''' एक्सएचआर ऑब्जेक्ट, ब्राउज़र-सर्वर संचार के लिए अजाक्स अनुप्रयोगों द्वारा उपयोग किया जाने वाला उपकरण, एक्सएचआर प्रतिक्रिया के लिए कस्टम डेटा प्रारूप उत्पन्न करके और ब्राउज़र का उपयोग करके प्रत्येक ईवेंट को पार्स करके सर्वर-ब्राउज़र कॉमेट मैसेजिंग के लिए सेवा में दबाया जा सकता है, इसके फलस्वरूप साइड जावास्क्रिप्ट, केवल ब्राउज़र फायरिंग पर भरोसा करते हुए <code>onreadystatechange</code> कॉलबैक हर बार यह नया डेटा प्राप्त करता है।
 
=== लांग पोलिंग के साथ अजाक्स का उपयोग ===
उपरोक्त स्ट्रीमिंग ट्रांसपोर्ट में से कोई भी ऋणात्मक साइड-इफेक्ट के बिना सभी आधुनिक ब्राउज़रों में कार्य नहीं करता है। यह काॅमेट डेवलपर्स को ब्राउज़र के आधार पर उनके बीच स्विच करने, कई जटिल स्ट्रीमिंग ट्रांसपोर्ट को लागू करने के लिए मजबूर करता है। इस प्रकार इसके परिणामस्वरूप इस प्रकार की कई काॅमेट अनुप्रयोग लांग पोलिंग का उपयोग करते हैं, जो कि ब्राउज़र पक्ष पर लागू करना आसान है, और एक्सएचआर का समर्थन करने वाले प्रत्येक ब्राउज़र में कम से कम कार्य करता है। जैसा कि नाम से पता चलता है, लांग पोलिंग के लिए क्लाइंट को किसी ईवेंट (या ईवेंट के सेट) के लिए सर्वर को पोल करने की आवश्यकता होती है। इस प्रकार ब्राउज़र सर्वर के लिए अजाक्स-शैली का अनुरोध करता है, जो तब तक ओपेन रहता है जब तक सर्वर के पास ब्राउज़र को भेजने के लिए नया डेटा नहीं होता है, जो ब्राउज़र को पूर्ण प्रतिक्रिया में भेजा जाता है। जिसके बाद की घटनाओं को प्राप्त करने के लिए ब्राउज़र नया लांग पोलिंग अनुरोध प्रारंभ करता है। [rfc:6202 आईईटीएफ आरएफसी 6202 लॉन्ग पोलिंग और द्विदिश एचटीटीपी में स्ट्रीमिंग के उपयोग के लिए ज्ञात विवाद और सर्वोत्तम अभ्यास] लंबे पोलिंग और एचटीटीपी स्ट्रीमिंग की तुलना करता है।
 
लांग पोलिंग को पूरा करने के लिए विशिष्ट तकनीकों में निम्नलिखित सम्मिलित हैं:


====[[XML]]Httpलंबी पोलिंग का अनुरोध करें====
====[[XML|एक्स एमएल]]एचटीटीपी लांग पोलिंग का अनुरोध करें====
अधिकांश भाग के लिए, XMLHttpRequest लंबा मतदान XHR के किसी भी मानक उपयोग की तरह काम करता है। ब्राउज़र सर्वर के लिए अतुल्यकालिक अनुरोध करता है, जो प्रतिक्रिया देने से पहले डेटा के उपलब्ध होने की प्रतीक्षा कर सकता है। प्रतिक्रिया में क्लाइंट द्वारा निष्पादित किए जाने वाले एन्कोडेड डेटा (आमतौर पर XML या JSON) या जावास्क्रिप्ट शामिल हो सकते हैं। प्रतिक्रिया के प्रसंस्करण के अंत में, ब्राउज़र अगली घटना की प्रतीक्षा करने के लिए और एक्सएचआर बनाता है और भेजता है। इस प्रकार ब्राउज़र हमेशा सर्वर के साथ अनुरोध बकाया रखता है, जिसका उत्तर प्रत्येक घटना के रूप में दिया जाता है।
अधिकांश भाग के लिए, एक्स एमएलएचटीटीपी रिक्वेस्ट लांग पोलिंग एक्सएचआर के किसी भी मानक उपयोग के आधार पर कार्य करता है। इस प्रकार ब्राउज़र सर्वर के लिए अतुल्यकालिक अनुरोध करता है, जो प्रतिक्रिया देने से पहले डेटा के उपलब्ध होने की प्रतीक्षा कर सकता है। प्रतिक्रिया में क्लाइंट द्वारा निष्पादित किए जाने वाले एन्कोडेड डेटा (सामान्यतः एक्स एमएल या जेसाॅन) या जावास्क्रिप्ट सम्मिलित हो सकते हैं। इस प्रकार की प्रतिक्रिया के प्रसंस्करण के अंत में, ब्राउज़र अगली घटना की प्रतीक्षा करने के लिए और एक्सएचआर बनाता है और भेजता है। इस प्रकार ब्राउज़र सदैव सर्वर के साथ अनुरोध बकाया रखता है, जिसका उत्तर प्रत्येक घटना के रूप में दिया जाता है।


====स्क्रिप्ट टैग लंबे समय तक मतदान ====
====स्क्रिप्ट टैग लंबे समय तक पोलिंग ====
जबकि किसी भी धूमकेतु परिवहन को [[उप डोमेन]] में काम करने के लिए बनाया जा सकता है, [[ क्रॉस साइट स्क्रिप्टिंग |क्रॉस साइट स्क्रिप्टिंग]] हमलों को रोकने के लिए डिज़ाइन की गई ब्राउज़र सुरक्षा नीतियों के कारण उपरोक्त में से कोई भी परिवहन दूसरे स्तर के डोमेन (एसएलडी) में उपयोग नहीं किया जा सकता है।<ref name="xss">{{cite book
जबकि किसी भी काॅमेट परिवहन को [[उप डोमेन]] में कार्य करने के लिए बनाया जा सकता है, [[ क्रॉस साइट स्क्रिप्टिंग |क्रॉस साइट स्क्रिप्टिंग]] हमलों को रोकने के लिए डिज़ाइन की गई ब्राउज़र सुरक्षा नीतियों के कारण उपरोक्त में से कोई भी परिवहन दूसरे स्तर के डोमेन (एसएलडी) में उपयोग नहीं किया जा सकता है।<ref name="xss">{{cite book
|last=Flanagan
|last=Flanagan
|first=David
|first=David
Line 162: Line 160:
|chapter=13.8.4 Cross-Site Scripting
|chapter=13.8.4 Cross-Site Scripting
|page=[https://archive.org/details/javascript00libg_297/page/n981 994]
|page=[https://archive.org/details/javascript00libg_297/page/n981 994]
}}</ref> अर्थात्, यदि मुख्य वेब पेज एसएलडी से सर्व किया जाता है, और कॉमेट सर्वर दूसरे एसएलडी (जिसमें [[क्रॉस-ऑरिजनल रिसोर्स शेयरिंग]] सक्षम नहीं है) पर स्थित है, तो धूमकेतु घटनाओं का उपयोग मुख्य के एचटीएमएल और डोम को संशोधित करने के लिए नहीं किया जा सकता है। पृष्ठ, उन परिवहन का उपयोग कर। या दोनों स्रोतों के सामने [[प्रॉक्सी सर्वर]] बनाकर इस समस्या को दूर किया जा सकता है, जिससे उन्हें ही डोमेन से उत्पन्न होने का आभास होता है। हालांकि, जटिलता या प्रदर्शन कारणों से यह अक्सर अवांछनीय होता है।
}}</ref> इस प्रकार यदि मुख्य वेब पेज एसएलडी से सर्व किया जाता है, और कॉमेट सर्वर दूसरे एसएलडी (जिसमें [[क्रॉस-ऑरिजनल रिसोर्स शेयरिंग]] सक्षम नहीं है) पर स्थित है, तो काॅमेट घटनाओं का उपयोग मुख्य के एचटीएमएल और डोम को संशोधित करने के लिए नहीं किया जा सकता है। इस प्रकार इन परिवहन का उपयोग कर सकते हैं। जिसके फलस्वरूप दोनों स्रोतों के सामने [[प्रॉक्सी सर्वर]] बनाकर इस समस्या को दूर किया जा सकता है, जिससे उन्हें ही डोमेन से उत्पन्न होने का आभास होता है। चूंकि, जटिलता या प्रदर्शन कारणों से यह सदैव अवांछनीय होता है।


आइफ्रेम या XMLHttpRequest ऑब्जेक्ट के विपरीत, <code>script</code> टैग किसी भी [[यूनिफॉर्म रिसोर्स पहचानकर्ता]] पर इंगित किए जा सकते हैं, और प्रतिक्रिया में जावास्क्रिप्ट कोड को वर्तमान HTML दस्तावेज़ में निष्पादित किया जाएगा। यह शामिल दोनों सर्वरों के लिए संभावित सुरक्षा जोखिम पैदा करता है, हालांकि [[JSONP]] का उपयोग करके डेटा प्रदाता (हमारे मामले में, धूमकेतु सर्वर) के लिए जोखिम से बचा जा सकता है।
आइफ्रेम या एक्स एमएलएचटीटीपीरिक्वेस्ट ऑब्जेक्ट के विपरीत, <code>script</code> टैग किसी भी [[यूनिफॉर्म रिसोर्स पहचानकर्ता]] पर इंगित किए जा सकते हैं, और प्रतिक्रिया में जावास्क्रिप्ट कोड को वर्तमान एचटीएमएल डाक्यूमेंट में निष्पादित किया जाएगा। यह सम्मिलित दोनों सर्वरों के लिए संभावित सुरक्षा के खतरे उत्पन्न करता है, चूंकि [[JSONP|जेसाॅन पी]] का उपयोग करके डेटा प्रदाता मुख्य रूप से हमारे इस स्थिति में, काॅमेट सर्वर के लिए उत्पन्न होने वाले इस खतरे से बचा जा सकता है।


गतिशील रूप से निर्माण करके लंबी मतदान धूमकेतु परिवहन बनाया जा सकता है <code>script</code> तत्व, और उनके स्रोत को धूमकेतु सर्वर के स्थान पर सेट करना, जो उसके पेलोड के रूप में कुछ घटना के साथ जावास्क्रिप्ट (या JSONP) को वापस भेजता है। हर बार जब स्क्रिप्ट अनुरोध पूरा हो जाता है, तो ब्राउज़र नया ब्राउज़र खोलता है, ठीक उसी तरह जैसे XHR लॉन्ग पोलिंग केस में होता है। क्रॉस-डोमेन कार्यान्वयन की अनुमति देते हुए भी इस पद्धति का क्रॉस-ब्राउज़र होने का लाभ है।<ref name="xss"/>
गतिशील रूप से निर्माण करके लांग पोलिंग काॅमेट परिवहन बनाया जा सकता है, इस प्रकार <code>script</code> एलिमेंट, और उनके स्रोत को काॅमेट सर्वर के स्थान पर सेट करना, जो इस प्रकार उसके पेलोड के रूप में कुछ घटना के साथ जावास्क्रिप्ट (या जेसाॅनपी) को वापस भेजता है। हर बार जब स्क्रिप्ट अनुरोध पूरा हो जाता है, तो ब्राउज़र नया ब्राउज़र ओपेन करता है, ठीक उसी प्रकार जैसे एक्सएचआर लॉन्ग पोलिंग केस में होता है। क्रॉस-डोमेन कार्यान्वयन की अनुमति देते हुए भी इस पद्धति का क्रॉस-ब्राउज़र होने का लाभ है।<ref name="xss" />
== विकल्प ==
== विकल्प ==
ब्राउज़र-देशी प्रौद्योगिकियां धूमकेतु शब्द में निहित हैं। गैर-मतदान HTTP संचार को बेहतर बनाने के प्रयास कई पक्षों से आए हैं:
ब्राउज़र-देशी प्रौद्योगिकियां काॅमेट शब्द में निहित हैं। गैर-पोलिंग एचटीटीपी संचार को बेहतर बनाने के प्रयास कई पक्षों से आए हैं:


* [[वेब हाइपरटेक्स्ट एप्लिकेशन टेक्नोलॉजी वर्किंग ग्रुप]] (WHATWG) द्वारा तैयार किया गया [[HTML 5]] ड्राफ्ट विनिर्देश कथित सर्वर-भेजे गए ईवेंट को निर्दिष्ट करता है,<ref name='server-sent-events'>{{cite web|editor=Ian Hickson |date=2007-10-27 |work=HTML 5 - Call For Comments|title=6.2 Server-sent DOM events|url=http://www.whatwg.org/specs/web-apps/2007-10-26/multipage/section-server-sent-events.html#server-sent-events |publisher=[[WHATWG]]|access-date=2008-10-07}}</ref> जो नए जावास्क्रिप्ट इंटरफ़ेस को परिभाषित करता है <code>EventSource</code> और नया MIME प्रकार <code>text/event-stream</code>. Server-sent_events#Web_browsers में यह तकनीक शामिल है।
* [[वेब हाइपरटेक्स्ट एप्लिकेशन टेक्नोलॉजी वर्किंग ग्रुप]] (WHATWG) द्वारा तैयार किया गया [[HTML 5|एचटीएमएल 5]] ड्राफ्ट विनिर्देश कथित सर्वर-भेजे गए ईवेंट को निर्दिष्ट करता है,<ref name='server-sent-events'>{{cite web|editor=Ian Hickson |date=2007-10-27 |work=HTML 5 - Call For Comments|title=6.2 Server-sent DOM events|url=http://www.whatwg.org/specs/web-apps/2007-10-26/multipage/section-server-sent-events.html#server-sent-events |publisher=[[WHATWG]]|access-date=2008-10-07}}</ref> जो इस प्रकार नए जावास्क्रिप्ट इंटरफ़ेस को परिभाषित करता है <code>EventSource</code> और नया एमआईएमई प्रकार <code>text/event-stream</code>. Server-sent_events#Web_browsers में यह तकनीक सम्मिलित है।
* HTML 5 WebSocket API वर्किंग ड्राफ्ट सर्वर के साथ लगातार कनेक्शन बनाने और संदेश प्राप्त करने के लिए विधि निर्दिष्ट करता है <code>onmessage</code> वापस कॉल करें।<ref>
* एचटीएमएल 5 वेब स्ट्रोक एपीआई वर्किंग ड्राफ्ट सर्वर के साथ निरंतर कनेक्शन बनाने और संदेश प्राप्त करने के लिए विधि निर्दिष्ट करता है <code>onmessage</code> वापस कॉल करें।<ref>
{{cite web
{{cite web
|url=http://www.w3.org/TR/websockets/
|url=http://www.w3.org/TR/websockets/
Line 182: Line 180:
}}
}}
</ref>
</ref>
* [[डोजो फाउंडेशन]] की ओर से बेयक्‍स प्रोटोकॉल। यह ब्राउज़र-विशिष्ट ट्रांसपोर्ट को जगह में छोड़ देता है, और ब्राउज़र और सर्वर के बीच संचार के लिए उच्च-स्तरीय प्रोटोकॉल को परिभाषित करता है, जिसका उद्देश्य [[क्लाइंट-साइड जावास्क्रिप्ट]] कोड को कई धूमकेतु सर्वरों के साथ पुन: उपयोग करने की अनुमति देता है, और उसी धूमकेतु सर्वर को संचार करने की अनुमति देता है। एकाधिक क्लाइंट-साइड जावास्क्रिप्ट कार्यान्वयन के साथ। Bayeux प्रकाशित/सदस्यता मॉडल पर आधारित है, इसलिए Bayeux का समर्थन करने वाले सर्वर में अंतर्निहित प्रकाशित/सदस्यता है।<ref name="bayeux">{{cite web|author=Alex Russell |year=2007 |url=http://svn.cometd.org/trunk/bayeux/bayeux.html|title=बेयक्‍स प्रोटोकॉल - बायक्‍यूम 1.0ड्राफ्ट1।| publisher= Dojo Foundation| access-date=2007-12-14|display-authors=etal}}</ref>
* [[डोजो फाउंडेशन]] की ओर से बेयक्‍स प्रोटोकॉल। यह ब्राउज़र-विशिष्ट ट्रांसपोर्ट को जगह में छोड़ देता है, और ब्राउज़र और सर्वर के बीच संचार के लिए उच्च-स्तरीय प्रोटोकॉल को परिभाषित करता है, जिसका उद्देश्य [[क्लाइंट-साइड जावास्क्रिप्ट]] कोड को कई काॅमेट सर्वरों के साथ पुन: उपयोग करने की अनुमति देता है, और इस प्रकार उसी काॅमेट सर्वर को संचार करने की अनुमति देता है। एकाधिक क्लाइंट-साइड जावास्क्रिप्ट कार्यान्वयन के साथ बिना इसके उपयोग किए प्रकाशित/सदस्यता प्रारूप पर आधारित है, इसलिए बेयुक्स का समर्थन करने वाले सर्वर में अंतर्निहित प्रकाशित/सदस्यता है।<ref name="bayeux">{{cite web|author=Alex Russell |year=2007 |url=http://svn.cometd.org/trunk/bayeux/bayeux.html|title=बेयक्‍स प्रोटोकॉल - बायक्‍यूम 1.0ड्राफ्ट1।| publisher= Dojo Foundation| access-date=2007-12-14|display-authors=etal}}</ref>
* एक्सएमपीपी मानक फाउंडेशन द्वारा [[बॉश (प्रोटोकॉल)]] प्रोटोकॉल। यह दो तुल्यकालिक HTTP कनेक्शन का उपयोग करके ब्राउज़र और सर्वर के बीच द्विदिश धारा का अनुकरण करता है।
* एक्सएमपीपी मानक फाउंडेशन द्वारा [[बॉश (प्रोटोकॉल)]] प्रोटोकॉल किया जाता हैं। यह दो तुल्यकालिक एचटीटीपी कनेक्शन का उपयोग करके ब्राउज़र और सर्वर के बीच द्विदिश धारा का अनुकरण करता है।
* डगलस क्रॉकफ़ोर्ड द्वारा प्रस्तावित JSONRequest ऑब्जेक्ट, XHR ऑब्जेक्ट का विकल्प होगा।<ref>{{cite web
* डगलस क्रॉकफ़ोर्ड द्वारा प्रस्तावित जेसाॅन रिक्वेस्ट ऑब्जेक्ट, एक्सएचआर ऑब्जेक्ट का विकल्प होगा।<ref>{{cite web
|url=http://www.json.org/JSONRequest.html
|url=http://www.json.org/JSONRequest.html
|title = JSONRequest Duplex
|title = JSONRequest Duplex
Line 193: Line 191:
|access-date = 2008-05-05
|access-date = 2008-05-05
}}</ref>
}}</ref>
* प्लगइन्स का उपयोग, जैसे कि जावा एप्लेट्स या मालिकाना [[एडोब फ्लैश]] (फ्लैश अनुप्रयोगों के लिए डेटा स्ट्रीमिंग के लिए [[रीयल-टाइम मैसेजिंग प्रोटोकॉल]] प्रोटोकॉल का उपयोग करना)। उपयुक्त प्लगइन के साथ सभी ब्राउज़रों में समान रूप से काम करने का फायदा है और HTTP कनेक्शन पर भरोसा करने की आवश्यकता नहीं है, लेकिन प्लगइन को स्थापित करने की आवश्यकता का नुकसान
* प्लगइन्स का उपयोग, जैसे कि जावा एप्लेट्स [[एडोब फ्लैश]] जो मुख्य रूप से फ्लैश अनुप्रयोगों के लिए डेटा स्ट्रीमिंग के लिए [[रीयल-टाइम मैसेजिंग प्रोटोकॉल]] प्रोटोकॉल का उपयोग करता हैं। इस प्रकार से उपयुक्त प्लगइन के साथ सभी ब्राउज़रों में समान रूप से कार्य करने का लाभ मिलता है, और इस प्रकार एचटीटीपी कनेक्शन पर भरोसा करने की आवश्यकता नहीं है, अपितु प्लगइन को स्थापित करने की आवश्यकता की हानि नहीं होती हैं
* [[गूगल]] ने घोषणा की<ref>App, The. (2010-12-02) [http://googleappengine.blogspot.com/2010/12/happy-holidays-from-app-engine-team-140.html Google App Engine Blog: Happy Holidays from the App Engine team - 1.4.0 SDK released]. Googleappengine.blogspot.com. Retrieved on 2014-04-12.</ref> Google ऐप इंजन के लिए नया चैनल एपीआई,<ref>Paul, Ryan. (2010-12-06) [https://arstechnica.com/web/news/2010/12/app-engine-gets-streaming-api-and-longer-background-tasks.ars App Engine gets Streaming API and longer background tasks]. Ars Technica. Retrieved on 2014-04-12.</ref> ब्राउजर पर क्लाइंट जावास्क्रिप्ट लाइब्रेरी की मदद से कॉमेट जैसी एपीआई को लागू करना। इस एपीआई को बहिष्कृत कर दिया गया है। <ref>{{cite web |url=https://cloud.google.com/appengine/docs/standard/java/javadoc/com/google/appengine/api/channel/package-summary |title=पैकेज com.google.appengine.api.channel|publisher=[[Google]] |date=2019-11-16 |access-date=2020-04-30 |quote=This API has been deprecated. }}</ref>
* इस प्रकार [[गूगल]] ने घोषणा की कि<ref>App, The. (2010-12-02) [http://googleappengine.blogspot.com/2010/12/happy-holidays-from-app-engine-team-140.html Google App Engine Blog: Happy Holidays from the App Engine team - 1.4.0 SDK released]. Googleappengine.blogspot.com. Retrieved on 2014-04-12.</ref> गूगल ऐप इंजन के लिए नया चैनल एपीआई,<ref>Paul, Ryan. (2010-12-06) [https://arstechnica.com/web/news/2010/12/app-engine-gets-streaming-api-and-longer-background-tasks.ars App Engine gets Streaming API and longer background tasks]. Ars Technica. Retrieved on 2014-04-12.</ref> ब्राउजर पर क्लाइंट जावास्क्रिप्ट लाइब्रेरी की सहायता से कॉमेट जैसी एपीआई को लागू करना। इस एपीआई को बहिष्कृत कर दिया गया है। <ref>{{cite web |url=https://cloud.google.com/appengine/docs/standard/java/javadoc/com/google/appengine/api/channel/package-summary |title=पैकेज com.google.appengine.api.channel|publisher=[[Google]] |date=2019-11-16 |access-date=2020-04-30 |quote=This API has been deprecated. }}</ref>
== यह भी देखें ==
== यह भी देखें ==
* धक्का प्रौद्योगिकी
* पुश प्रौद्योगिकी
* [[प्रौद्योगिकी खींचो]]
* [[प्रौद्योगिकी खींचो|पुल प्रौद्योगिकी]]


==संदर्भ==
==संदर्भ==

Revision as of 21:27, 22 June 2023

काॅमेट प्रोग्रामिंग वेब अनुप्रयोग ऐसा प्रारूप है जिसमें लंबे समय से आयोजित होने वाले एचटीटीपीS पेज को वेब सर्वर द्वारा विभिन्न वेब ब्राउज़र के लिए तकनीकी रूप से डेटा को पुश करने की अनुमति देता है, इसके बिना ब्राउज़र को स्पष्ट रूप से अनुरोध किया जाता हैं।[1][2] काॅमेट ऐसा शब्द है, जिसमें इस अंतःक्रिया को प्राप्त करने के लिए कई तकनीकों को सम्मिलित किया गया है। ये सभी विधियाँ गैर-डिफ़ॉल्ट प्लगइन्स के अतिरिक्त ब्राउज़रों में डिफ़ॉल्ट रूप से सम्मिलित सुविधाओं पर निर्भर करती हैं, जैसे कि जावास्क्रिप्ट इसका उत्तम उदाहरण हैं। इस प्रकार काॅमेट का दृष्टिकोण वर्ल्ड वाइड वेब फंक्शन से भिन्न है, जिसमें ब्राउज़र समय में पूर्ण वेब पेज का अनुरोध करता है।[3]

वेब विकास में काॅमेट तकनीकों का उपयोग सामूहिक तकनीकों के लिए निओलिज़्म के रूप में काॅमेट शब्द के उपयोग से पहले का है। इस प्रकार काॅमेट सहित कई अन्य नामों जैसे अजाक्स पुश,[4][5] रिवर्स अजाक्स,[6] टू-वे-वेब,[7] एचटीटीपी स्ट्रीमिंग,[7] और एचटीटीपी पुश[8] से जाना जाता है।[9] इस प्रकार कॉमेट शब्द संक्षिप्त शब्द नहीं है, अपितु एलेक्स रसेल ने अपने 2006 के ब्लॉग पोस्ट कॉमेट: लो लेटेंसी डेटा फॉर द ब्राउजर में बनाया गया था।[10] वर्तमान समय के कुछ वर्षों में, वेबसॉकेट और सर्वर-भेजे गए कार्यक्रमों के मानकीकरण और व्यापक समर्थन ने काॅमेट प्रारूप को अप्रचलित कर दिया है।

इतिहास

प्रारंभिक जावा एप्लेट्स

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

सर्वप्रथम ब्राउज़र-टू-ब्राउज़र संचार प्रारूप

ब्राउज़र-टू-ब्राउज़र संचार का उपयोग करने वाला पहला एप्लिकेशन टैंगो इंटरएक्टिव था,[13] इस प्रकार 1996-98 में नॉर्थईस्ट पैरेलल आर्किटेक्चर सेंटर (एनपीएसी) में सिराकस यूनिवर्सिटी में डार्पा फंडिंग का उपयोग करके लागू किया गया था। इसके अनुसार टैंगो संरचना को सिरैक्यूज़ विश्वविद्यालय द्वारा पेटेंट कराया गया है।[14] इस प्रकार दूरस्थ शिक्षा उपकरण के रूप में टैंगो प्रारूप का बड़े पैमाने पर उपयोग किया गया है।[15] कोलैब वर्क्स द्वारा इस प्रारूप का व्यावसायीकरण किया गया है और संयुक्त राज्य अमेरिका के रक्षा विभाग में दर्जन या इतने ही कमान और नियंत्रण और प्रशिक्षण अनुप्रयोगों में उपयोग किया गया है।.

सर्वप्रथम काॅमेट अनुप्रयोग

काॅमेट कार्यान्वयन का पहला सेट 2000 से पहले का है,[16] जिसे पुशलेट्स, लाइट स्ट्रीमर, और नो नाओ परियोजनाओं के साथ प्रदर्शित किया गया था। इस प्रकार पुशलेट्स, जस्ट वैन डेन ब्रौएके द्वारा बनाया गया प्रारूप सबसे पहले उपयोग किया गया था[17] इस प्रकार ओपेन स्रोत कार्यान्वयन के लिए पुशलेट सर्वर-साइड जावा सर्वलेट्स और क्लाइंट-साइड जावास्क्रिप्ट लाइब्रेरी पर आधारित थे। जिसके कारण बैंग नेटवर्क – नेटस्केप के सह-संस्थापक मार्क आंद्रेसेन द्वारा समर्थित सिलिकॉन वैली स्टार्ट-अप के पास संपूर्ण वेब के लिए रीयल-टाइम पुश मानक बनाने का भरपूर वित्तपोषित प्रयास था।[18] इस प्रकार अप्रैल 2001 में, चिप मॉर्निंगस्टार ने जावा-आधारित (J2SE) वेब सर्वर विकसित करना प्रारंभ कर दिया था, जो इसके परिणामस्वरूप दो एचटीटीपी सॉकेट का उपयोग करने में सक्षम थे, इसके द्वारा डिज़ाइन किए गए कस्टम एचटीटीपी सर्वर और डगलस क्रॉकफोर्ड द्वारा डिज़ाइन किए गए क्लाइंट के बीच दो संचार चैनलों को ओपेन रखता था, जून 2001 तक कार्यशील डेमो सिस्टम अस्तित्व में आया था। जिसके परिणामस्वरूप सर्वर और क्लाइंट ने मैसेजिंग प्रारूप का उपयोग किया जिसे क्रॉकफोर्ड के सुझाव के बाद स्टेट सॉफ्टवेयर, इंक. के संस्थापकों ने जेसाॅन के रूप में बनाने के लिए सहमति दी थी। इस प्रकार संपूर्ण सिस्टम, क्लाइंट लाइब्रेरी, मैसेजिंग फॉर्मेट जिसे जेसाॅन और सर्वर के रूप में जाना जाता है, स्टेट एप्लिकेशन फ्रेमवर्क बन गया, जिसके कुछ भागों को सन माइक्रोसिस्टम, Amazon.com, ईडीएस और वोक्सवैगेन द्वारा बेचा और उपयोग किया गया था।

मार्च 2006 में, सॉफ्टवेयर इंजीनियर एलेक्स रसेल ने अपने निजी ब्लॉग पर पोस्ट में काॅमेट शब्द को चयनित किया।[19] इस नये शब्द अजाक्स (प्रोग्रामिंग) अजाक्स (क्लीन्ज़र) और काॅमेट (क्लीन्ज़र) दोनों संयुक्त राज्य अमेरिका में आम घरेलू क्लीनर होने पर प्रदर्शित होता था। [20][21][22]

2006 में, कुछ अनुप्रयोगों ने उन तकनीकों को व्यापक दर्शकों के सामने प्रस्तुत किया था: मीबो के बहु-प्रोटोकॉल वेब-आधारित चैट एप्लिकेशन ने उपयोगकर्ताओं को एओएल इंस्टेंट मैसेंजर, याहू! ब्राउज़र के माध्यम से मैसेंजर, और एमएसएन मैसेंजर चैट प्लेटफॉर्म, गूगल ने जीमेल लगीं में वेब-आधारित चैट को जोड़ा, जाॅट स्पाट, गूगल द्वारा अधिग्रहित होने के बाद से स्टार्टअप, ने काॅमेट-आधारित वास्तविक समय सहयोगी डाॅक्यूमेंट के संपादन का निर्माण किया था।[23] इस प्रकार से प्राप्त नए काॅमेट वेरिएंट बनाए गए थे, जैसे कि जावा-आधारित आईसीई फेसेज जावा सर्वर फेसेज फ्रेमवर्क हैं, चूंकि इस प्रकार अजाक्स पुश शब्द को उपयोग करते हैं,[5] इस प्रकार के अन्य पहले के जावा-एप्लेट आधारित ट्रांसपोर्ट का उपयोग करते थे, जो मुख्य रूप से शुद्ध-जावास्क्रिप्ट कार्यान्वयन के अतिरिक्त स्विच किए गए थे।[24]

कार्यान्वयन

काॅमेट अनुप्रयोग वर्ल्ड वाइड वेब फंक्शन या पेज से पेज के लिए वेब प्रारूप और पारंपरिक कंप्यूटर विज्ञान की सीमाओं को समाप्त करने का प्रयास करते हैं, सर्वर और के बीच निरंतर या लंबे समय तक चलने वाले एचटीटीपी कनेक्शन का उपयोग करके दो-तरफा निरंतर बातचीत की प्रस्तुत करते हैं। चूंकि इस प्रकार ब्राउज़र और प्रॉक्सी को सर्वर ईवेंट को ध्यान में रखकर नहीं बनाया गया है, इसलिए इसे प्राप्त करने के लिए कई तकनीकें विकसित की गई हैं, जिनमें से प्रत्येक के अलग-अलग लाभ और कमियां हैं। इस प्रकार इसकी सबसे बड़ी बाधा हाइपरटेक्स्ट से जुड़ी 1.1 विनिर्देश है, जो इस विनिर्देश को यह बताता है कि ग्राहकों को कई कनेक्शन ओपेन करते समय रूढ़िवादी होने के लिए प्रोत्साहित करता है।[25] इसलिए, वास्तविक समय की घटनाओं के लिए कनेक्शन ओपेन रखने से ब्राउज़र की उपयोगिता पर ऋणात्मक प्रभाव पड़ता है: पिछले अनुरोध के परिणामों की प्रतीक्षा करते समय ब्राउज़र को नया अनुरोध भेजने से रोका जा सकता है, उदाहरण के लिए इमेजेस की श्रृंखला इसका प्रमुख उदाहरण हैं। इस प्रकार वास्तविक समय की जानकारी के लिए अलग होस्ट का नाम बनाकर इसे हल किया जा सकता है, जो भौतिक सर्वर के लिए उपनाम है। यह रणनीति डोमेन शार्डिंग का अनुप्रयोग है।

काॅमेट को लागू करने के विशिष्ट तरीके दो प्रमुख श्रेणियों स्ट्रीमिंग और लांग में आते हैं।

स्ट्रीमिंग

स्ट्रीमिंग काॅमेट का उपयोग करने वाला एप्लिकेशन वेब ब्राउज़र से सभी कॉमेट घटना (कंप्यूटिंग) के लिए सर्वर पर सतत कनेक्शन को ओपेन करता है। इस प्रकार निरंतर सर्वर के नये ईवेंट को भेजता है, तो इन घटनाओं को ग्राहक की ओर से नियंत्रित और व्याख्यायित किया जाता है, जिसमें कोई भी पक्ष कनेक्शन बंद नहीं करता है।[3]

स्ट्रीमिंग काॅमेट को पूरा करने की विशिष्ट तकनीकों में निम्नलिखित सम्मिलित हैं:

हिडन आईफ्रेम

डायनेमिक वेब एप्लिकेशन के लिए मौलिक तकनीक छिपे हुए एचटीएमएल एलिमेंट को फ्रेम्स एचटीएमएल एलिमेंट के लिए इनलाइन फ्रेम, जो वेबसाइट को एचटीएमएल डाक्यूमेंट को दूसरे के अंदर एम्बेड करने की अनुमति देता है जो इसका उपयोग करता है। इस प्रकार यह हिडेन आईफ्रेम चुनकेड ट्रांसफर एन्कोडिंग ब्लॉक के रूप में भेजा जाता है, जो इसे असीमित रूप से लंबे समय तक घोषित करता है, जो कभी-कभी या सदैव इसके लिए फ्रेम किया जाता है। जैसे ही इस प्रकार की घटनाएं होती हैं, जो इस प्रकार आईफ्रेम को धीरे-धीरे भर देता है, जिसके फलस्वरूप script टैग, जिसमें ब्राउज़र में निष्पादित होने वाली जावास्क्रिप्ट सम्मिलित हो जाती है। क्योंकि ब्राउज़र एचटीएमएल पृष्ठों को वृद्धिशील रूप से प्रस्तुत करते हैं, प्रत्येक script टैग प्राप्त होते ही निष्पादित किया जाता है। कुछ ब्राउज़रों को पार्सिंग और निष्पादन प्रारंभ करने से पहले विशिष्ट न्यूनतम डाक्यूमेंट आकार की आवश्यकता होती है, जिसे प्रारंभ में 1-2 kB पैडिंग स्पेस भेजकर प्राप्त किया जा सकता है।[26]

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

एक्सएमएल एचटीटीपी रिक्वेस्ट

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

लांग पोलिंग के साथ अजाक्स का उपयोग

उपरोक्त स्ट्रीमिंग ट्रांसपोर्ट में से कोई भी ऋणात्मक साइड-इफेक्ट के बिना सभी आधुनिक ब्राउज़रों में कार्य नहीं करता है। यह काॅमेट डेवलपर्स को ब्राउज़र के आधार पर उनके बीच स्विच करने, कई जटिल स्ट्रीमिंग ट्रांसपोर्ट को लागू करने के लिए मजबूर करता है। इस प्रकार इसके परिणामस्वरूप इस प्रकार की कई काॅमेट अनुप्रयोग लांग पोलिंग का उपयोग करते हैं, जो कि ब्राउज़र पक्ष पर लागू करना आसान है, और एक्सएचआर का समर्थन करने वाले प्रत्येक ब्राउज़र में कम से कम कार्य करता है। जैसा कि नाम से पता चलता है, लांग पोलिंग के लिए क्लाइंट को किसी ईवेंट (या ईवेंट के सेट) के लिए सर्वर को पोल करने की आवश्यकता होती है। इस प्रकार ब्राउज़र सर्वर के लिए अजाक्स-शैली का अनुरोध करता है, जो तब तक ओपेन रहता है जब तक सर्वर के पास ब्राउज़र को भेजने के लिए नया डेटा नहीं होता है, जो ब्राउज़र को पूर्ण प्रतिक्रिया में भेजा जाता है। जिसके बाद की घटनाओं को प्राप्त करने के लिए ब्राउज़र नया लांग पोलिंग अनुरोध प्रारंभ करता है। [rfc:6202 आईईटीएफ आरएफसी 6202 लॉन्ग पोलिंग और द्विदिश एचटीटीपी में स्ट्रीमिंग के उपयोग के लिए ज्ञात विवाद और सर्वोत्तम अभ्यास] लंबे पोलिंग और एचटीटीपी स्ट्रीमिंग की तुलना करता है।

लांग पोलिंग को पूरा करने के लिए विशिष्ट तकनीकों में निम्नलिखित सम्मिलित हैं:

एक्स एमएलएचटीटीपी लांग पोलिंग का अनुरोध करें

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

स्क्रिप्ट टैग लंबे समय तक पोलिंग

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

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

गतिशील रूप से निर्माण करके लांग पोलिंग काॅमेट परिवहन बनाया जा सकता है, इस प्रकार script एलिमेंट, और उनके स्रोत को काॅमेट सर्वर के स्थान पर सेट करना, जो इस प्रकार उसके पेलोड के रूप में कुछ घटना के साथ जावास्क्रिप्ट (या जेसाॅनपी) को वापस भेजता है। हर बार जब स्क्रिप्ट अनुरोध पूरा हो जाता है, तो ब्राउज़र नया ब्राउज़र ओपेन करता है, ठीक उसी प्रकार जैसे एक्सएचआर लॉन्ग पोलिंग केस में होता है। क्रॉस-डोमेन कार्यान्वयन की अनुमति देते हुए भी इस पद्धति का क्रॉस-ब्राउज़र होने का लाभ है।[27]

विकल्प

ब्राउज़र-देशी प्रौद्योगिकियां काॅमेट शब्द में निहित हैं। गैर-पोलिंग एचटीटीपी संचार को बेहतर बनाने के प्रयास कई पक्षों से आए हैं:

  • वेब हाइपरटेक्स्ट एप्लिकेशन टेक्नोलॉजी वर्किंग ग्रुप (WHATWG) द्वारा तैयार किया गया एचटीएमएल 5 ड्राफ्ट विनिर्देश कथित सर्वर-भेजे गए ईवेंट को निर्दिष्ट करता है,[28] जो इस प्रकार नए जावास्क्रिप्ट इंटरफ़ेस को परिभाषित करता है EventSource और नया एमआईएमई प्रकार text/event-stream. Server-sent_events#Web_browsers में यह तकनीक सम्मिलित है।
  • एचटीएमएल 5 वेब स्ट्रोक एपीआई वर्किंग ड्राफ्ट सर्वर के साथ निरंतर कनेक्शन बनाने और संदेश प्राप्त करने के लिए विधि निर्दिष्ट करता है onmessage वापस कॉल करें।[29]
  • डोजो फाउंडेशन की ओर से बेयक्‍स प्रोटोकॉल। यह ब्राउज़र-विशिष्ट ट्रांसपोर्ट को जगह में छोड़ देता है, और ब्राउज़र और सर्वर के बीच संचार के लिए उच्च-स्तरीय प्रोटोकॉल को परिभाषित करता है, जिसका उद्देश्य क्लाइंट-साइड जावास्क्रिप्ट कोड को कई काॅमेट सर्वरों के साथ पुन: उपयोग करने की अनुमति देता है, और इस प्रकार उसी काॅमेट सर्वर को संचार करने की अनुमति देता है। एकाधिक क्लाइंट-साइड जावास्क्रिप्ट कार्यान्वयन के साथ बिना इसके उपयोग किए प्रकाशित/सदस्यता प्रारूप पर आधारित है, इसलिए बेयुक्स का समर्थन करने वाले सर्वर में अंतर्निहित प्रकाशित/सदस्यता है।[30]
  • एक्सएमपीपी मानक फाउंडेशन द्वारा बॉश (प्रोटोकॉल) प्रोटोकॉल किया जाता हैं। यह दो तुल्यकालिक एचटीटीपी कनेक्शन का उपयोग करके ब्राउज़र और सर्वर के बीच द्विदिश धारा का अनुकरण करता है।
  • डगलस क्रॉकफ़ोर्ड द्वारा प्रस्तावित जेसाॅन रिक्वेस्ट ऑब्जेक्ट, एक्सएचआर ऑब्जेक्ट का विकल्प होगा।[31]
  • प्लगइन्स का उपयोग, जैसे कि जावा एप्लेट्स एडोब फ्लैश जो मुख्य रूप से फ्लैश अनुप्रयोगों के लिए डेटा स्ट्रीमिंग के लिए रीयल-टाइम मैसेजिंग प्रोटोकॉल प्रोटोकॉल का उपयोग करता हैं। इस प्रकार से उपयुक्त प्लगइन के साथ सभी ब्राउज़रों में समान रूप से कार्य करने का लाभ मिलता है, और इस प्रकार एचटीटीपी कनेक्शन पर भरोसा करने की आवश्यकता नहीं है, अपितु प्लगइन को स्थापित करने की आवश्यकता की हानि नहीं होती हैं
  • इस प्रकार गूगल ने घोषणा की कि[32] गूगल ऐप इंजन के लिए नया चैनल एपीआई,[33] ब्राउजर पर क्लाइंट जावास्क्रिप्ट लाइब्रेरी की सहायता से कॉमेट जैसी एपीआई को लागू करना। इस एपीआई को बहिष्कृत कर दिया गया है। [34]

यह भी देखें

संदर्भ

  1. Krill, Paul (September 24, 2007). "AJAX गठबंधन मैशअप को पहचानता है". InfoWorld. Retrieved 2010-10-20.
  2. Crane, Dave; McCarthy, Phil (October 13, 2008). Comet and Reverse Ajax: The Next-Generation Ajax 2.0. Apress. ISBN 978-1-59059-998-3.
  3. 3.0 3.1 Gravelle, Rob. "Comet Programming: Using Ajax to Simulate Server Push". Webreference.com. Archived from the original on 2010-10-18. Retrieved 2010-10-20.
  4. Egloff, Andreas (2007-05-05). Ajax Push (a.k.a. Comet) with Java Business Integration (JBI) (Speech). JavaOne 2007, San Francisco, California: Sun Microsystems, Inc. Retrieved 2008-06-10.{{cite speech}}: CS1 maint: location (link)
  5. 5.0 5.1 "Ajax Push". ICEfaces.org. Retrieved 2014-10-23.
  6. Crane, Dave; McCarthy, Phil (July 2008). Comet and Reverse Ajax: The Next Generation Ajax 2.0. Apress. ISBN 1-59059-998-5.
  7. 7.0 7.1 Mahemoff, Michael (June 2006). "Web Remoting". Ajax Design Patterns. O'Reilly Media. pp. 19, 85. ISBN 0-596-10180-5.
  8. Double, Chris (2005-11-05). "More on Ajax and server push". Different ways of doing server push. Retrieved 2008-05-05.
  9. Nesbitt, Bryce (2005-11-01). "The Slow Load Technique/Reverse AJAX". Simulating Server Push in a Standard Web Browser. Archived from the original on 2006-02-08. Retrieved 2008-05-06.
  10. Russell, Alex (2006-03-04). "Comet: Low Latency Data for the Browser". Retrieved 2014-11-02.
  11. "नेटस्केप.कॉम". Archived from the original on November 15, 1996. Retrieved 2017-08-16.{{cite web}}: CS1 maint: bot: original URL status unknown (link)
  12. "java.net.Socket (Java 2 Platform SE v1.4.2)" Archived May 19, 2009, at the Wayback Machine
  13. Beca, Lukasz (1997). "TANGO - a Collaborative Environment for the World-Wide Web". Syracuse University SURFACE. Northeast Parallel Architecture Center, College of Engineering and Computer Science. Retrieved 27 February 2016.
  14. Podgorny, Marek; Beca, Lukasz; Cheng, Gang; Fox, Geoffrey C.; Jurga, Tomasz; Olszewski, Konrad; Sokolowski, Piotr; Walczak, Krzysztof; PL (June 20, 2000), United States Patent: 6078948 - Platform-independent collaboration backbone and framework for forming virtual communities having virtual rooms with collaborative sessions, retrieved 2016-02-27
  15. Baer, Troy (1999). "Experiences with Using TANGO Interactive in a Distributed Workshop" (PDF). CEWES Major Shared Resource Center. CEWES MSRC/PET TR/99-21. Retrieved 27 February 2016.
  16. "धूमकेतु दैनिक: धूमकेतु और धक्का प्रौद्योगिकी". Archived from the original on 2007-11-13. Retrieved 2007-12-15.
  17. Just van den Broecke (1 March 2000). “Pushlets: Send events from servlets to DHTML client browsers”. JavaWorld. Retrieved 1 August 2014.
  18. Borland, John (2001-04-01). "Will the "refresh" button become obsolete?". CNET Networks. Retrieved 2008-07-22.
  19. एलेक्स रसेल (3 मार्च 2006)। "धूमकेतु: ब्राउज़र के लिए कम विलंबता डेटा Archived 2008-08-12 at the Wayback Machine”। एलेक्स रसेल का ब्लॉग। 29 नवंबर 2007 को पुनःप्राप्त।
  20. K. Taft, Darryl (2006-05-12). "Microsoft ने AJAX टूल सेट से धूमकेतु को स्क्रब किया". eWEEK.com. Retrieved 2008-07-21.
  21. Orbited: Enabling Comet for the Masses: OSCON 2008 - O'Reilly Conferences, July 21 - 25, 2008, Portland, Oregon
  22. Enterprise Comet & Web 2.0 Live Presentation Archived 2008-05-20 at the Wayback Machine
  23. Dion Almaer (29 September 2005). “Jotspot Live: Live, group note-taking” (interview with Abe Fettig). Ajaxian. Retrieved 15 December 2007.
    Matt Marshall (15 December 2006). “Renkoo launches event service — in time to schedule holiday cocktails”. Venture Beat. Retrieved 15 December 2007.
  24. Clint Boulton (27 December 2005). “Startups Board the AJAX Bandwagon”. DevX News. Retrieved 18 February 2008.
  25. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing, section 6.4. IETF. Retrieved 2014-07-29
  26. 26.0 26.1 Holdener III, Anthony T. (January 2008). "Page Layout with Frames that Aren't". Ajax: The Definitive Guide. O'Reilly Media. p. 320. ISBN 0-596-52838-8.
  27. 27.0 27.1 Flanagan, David (2006-08-17). "13.8.4 Cross-Site Scripting". JavaScript the Definitive Guide. The Definitive Guide. O'Reilly Media. p. 994. ISBN 0-596-10199-6.
  28. Ian Hickson, ed. (2007-10-27). "6.2 Server-sent DOM events". HTML 5 - Call For Comments. WHATWG. Retrieved 2008-10-07.
  29. Hickson, Ian (2009-04-23). "The WebSocket API". W3C. Retrieved 2009-07-21.
  30. Alex Russell; et al. (2007). "बेयक्‍स प्रोटोकॉल - बायक्‍यूम 1.0ड्राफ्ट1।". Dojo Foundation. Retrieved 2007-12-14.
  31. Crockford, Douglas (2006-04-17). "JSONRequest Duplex". An alternative to XMLHttpRequest for long lasting server initiated push of data. Retrieved 2008-05-05.
  32. App, The. (2010-12-02) Google App Engine Blog: Happy Holidays from the App Engine team - 1.4.0 SDK released. Googleappengine.blogspot.com. Retrieved on 2014-04-12.
  33. Paul, Ryan. (2010-12-06) App Engine gets Streaming API and longer background tasks. Ars Technica. Retrieved on 2014-04-12.
  34. "पैकेज com.google.appengine.api.channel". Google. 2019-11-16. Retrieved 2020-04-30. This API has been deprecated.


बाहरी संबंध

  • "Comet Daily". Archived from the original on 2008-01-04. Retrieved 2007-11-29. Comet Daily provides information about Comet techniques.*