Socket.io: घटनाओं के लिए वाइल्डकार्ड समर्थन जोड़ें

मान गया।

EventEmitter2

+1
यह हमें फ़िल्टर बनाने की अनुमति देगा और सभी ईवेंट के लिए क्या नहीं।

• एक और निर्भरता
• ग्राहक के पक्ष में परिलक्षित होना चाहिए (कोड?)
• क्या कैटचेल को विशेष घटना से पहले बुलाया जाना चाहिए? या परिभाषा के क्रम में? स्पष्टीकरण की आवश्यकता
• केवल सिंक व्यवहार -- क्या ईवेंट के लिए कस्टम _async_ फ़िल्टर पेश करना बेहतर नहीं होगा?

+1

केवल सिंक व्यवहार -- क्या ईवेंट के लिए कस्टम async फ़िल्टर पेश करना बेहतर नहीं होगा?
@dvv

मुझे इस विचार में काफी दिलचस्पी है।

EE2 विकल्पों में से कुछ ऐसे नहीं हैं जिन्हें मैं आदर्श मानूंगा लेकिन मैं इसके सामान्य विचार को +1 करता हूं, भले ही केवल "*" समर्थित हो

सही मायने में पकड़: manager.on("event", function(client, event, data) {} -- बंद होने की संख्या को भी कम करने की अनुमति देगा

मुझे केवल एक कैटचेल श्रोता को जोड़ने के लिए कोई प्रतिरोध याद नहीं है, मुझे याद है कि एकमात्र बहस यह थी कि हम "*" का उपयोग करते हैं या नहीं या यदि हम किसी अन्य विधि नाम के साथ जाते हैं जैसे .addGlobalListener ()

+1
मुझे भी सभी घटनाओं को रोकने के लिए एक तरीके की आवश्यकता होगी, और विशिष्ट हैंडलर उन पर एक नज़र डालें, केवल एक बार जब मैं इसे संसाधित कर लेता हूं। अधिकतर लॉगिंग उद्देश्यों के लिए इसकी आवश्यकता होगी। Socket.io लकड़हारा वर्तमान में केवल कंसोल में लॉग करता है, और एक बहुत ही आत्म-धार्मिक तरीके से।
DVv -s दृष्टिकोण वास्तव में मेरी पसंद का है।
वास्तव में शायद यह एक अच्छा विचार होगा कि हम घटना को किसी विशिष्ट हैंडलर को रिले करें, और हम सभी घटनाओं को प्राप्त करते हैं, जैसा कि डीवीवी द्वारा वर्णित है।

कृपया इस मुद्दे को गति दें :)
इस सुविधा को लागू होते देखना पसंद करेंगे।

ठीक है, ठीक है, मैंने अभी अपने कांटे में एक शाखा में EE2 जोड़ा है: https://github.com/einaros/socket.io/commit/2107ff00f3ddf2d781d3e3c3b7dfb1fc990f7ec5

शाखा यहां है: https://github.com/einaros/socket.io/commits/ee2

विचारों का स्वागत है।

अगर EE2 अजीब विधि नामों से छुटकारा पाता है और .on('*') जोड़ता है तो मैं इसे +1 कर दूंगा

मैं EE2 पर -1 हूं

यह कोड में और अधिक ब्लोट जोड़ता है, हमें क्लाइंट साइड पर भी इसका समर्थन करने की आवश्यकता है। जिसका अर्थ है कि हमें अतिरिक्त 11.8 केबी पुस्तकालय (मिनीफाइड ~ 3.5 केबी) भेजना होगा। लेकिन आने वाले मोबाइल बाजार के साथ मैं ज्यादा से ज्यादा बाइट बचाना चाहूंगा।

यदि यह वास्तव में केवल वाइल्डकार्ड/सभी श्रोताओं को पकड़ने के बारे में है .. तो यह मौजूदा उत्सर्जन फ़ंक्शन को ओवरराइड करके किया जाना चाहिए जो all श्रोता को केवल एक अतिरिक्त कॉल करता है। यह 3 - 5 LOC परिवर्तन की तरह होगा (टिप्पणियों को छोड़कर;))। और वरीयता लॉक के पीछे छिपा होना चाहिए क्योंकि यह प्रदर्शन को प्रभावित करता है। EventEmitting एक हॉट कोड पथ है और हमेशा यथासंभव इष्टतम और तेज़ होना चाहिए। वाइल्डकार्ड जोड़ने से प्रदर्शन खराब हो जाएगा।

कैच-ऑल निश्चित रूप से अधिक महत्वपूर्ण हिस्सा है, यदि आवश्यक हो तो उसके बाद ईवेंट को चालू करना काफी आसान है

वाइल्डकार्ड, या EE2 के बारे में वास्तव में परवाह नहीं है, लेकिन सभी घटनाओं को रोकने के लिए एक तरीका जरूरी है।

अगर EE2 ... जोड़ता है .on('*') मैं उसे +1 कर दूंगा

टीजे यू क्रेजी भाई...

server.on('foo.*', function(value1, value2) {
  console.log(this.event, value1, value2);
});

वह EE2 के README से है। स्वाभाविक रूप से, "फू।" वैकल्पिक है।

अगर EE2 अजीब विधि नामों से छुटकारा पाता है

मैं सहमत हूं।

@pyrotechnick EE2 .on('*') एक कैच-ऑल iirc नहीं है

* इस अर्थ में कैच-ऑल नहीं है कि यह सभी घटनाओं को आँख बंद करके पकड़ लेता है लेकिन यह सभी घटनाओं को प्रभावी ढंग से पकड़ लेता है क्योंकि पैटर्न * सभी चैनलों से मेल खाता है।

यह अक्षम है; लेकिन यह अपेक्षा के अनुरूप काम करता है।

मुझे गलत समझा गया था। आप सही हे...

{EventEmitter2} = require 'eventemitter2'

emitter = new EventEmitter2 wildcard: on

emitter.on '*', ->
  console.log <strong i="6">@event</strong>, arguments...

emitter.emit 'foo'
emitter.emit 'foo.bar'

isabel:hydrogen pyrotechnick$ coffee test.coffee 
foo

जब वाइल्डकार्ड की बात आती है तो मैं लगभग इस व्यवहार को पसंद करता हूं।

जब मैं इन सभी वाइल्डकार्ड/"नेमस्पेस्ड" घटनाओं के बारे में सोचता हूं तो यह मुझे दुखी करता है; जावास्क्रिप्ट में पहले से ही पैटर्न से मेल खाने का एक शानदार तरीका है - वे // में रहते हैं या RegExp साथ बनाए गए हैं। क्या यह अभी बहुत धीमा है?

क्या मैं इसके महत्व को फिर से +1 कर सकता हूं। मैं इसे आगामी रिलीज में देखना पसंद करूंगा।

किसी ने यहां समाधान पोस्ट किया: http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

यह काम नहीं करता क्योंकि मैं अभी भी इवेंट से कनेक्ट नहीं हो पा रहा हूं। मेरे आवेदन में सर्वर क्लाइंट से कमरे का नाम नहीं जानता है। इसलिए मैं किसी भी कमरे के सभी संदेशों का जवाब देने में सक्षम होना चाहता हूं और आदर्श रूप से उस कमरे का नाम पता लगाना चाहता हूं जिस पर संदेश भेजा गया था।

घटनाओं के लिए नियमित अभिव्यक्ति समर्थन जोड़ें .. इस तरह, क्रियाओं और संज्ञाओं की श्रेणी को पकड़ा जा सकता है।

+1

+1

+1

+1

+1

मुझे एक सुपर ग्लोबल पद्धति का शौक होगा जो सब कुछ संभालती है

io.set('global_listener', function(namespace, event, args, emit){
// नेमस्पेस इवेंट और तर्कों के आधार पर कुछ करें
// मैं उस नेमस्पेस और उस इवेंट से जुड़े इवेंट श्रोताओं को कॉल करने के लिए एमिट () को कॉल कर सकता हूं या नहीं
});

io.set('global_authorization', function(namespace, handshakeData, कॉलबैक){
// नेमस्पेस और हैंडशेक के आधार पर डेटा कनेक्शन स्वीकार करता है या नहीं
});

मुझे एक एमिटर की जरूरत थी जो कैच-ऑल ए का समर्थन करता हो। ला. socket.on("*") , क्लाइंट पर काम किया, और अभी भी हल्का वजन था। इसलिए मैंने UI किट से @visionmedia का एमिटर लिया और इसे थोड़ा बढ़ाया। शायद यह इसके लिए उपयुक्त होगा। तो, इसके लायक क्या है। मैं इसे यहाँ छोड़ दूँगा: https://github.com/HenrikJoreteg/wildemitter

@ हेनरिक जोरेटेग
हम बॉक्स के बाहर '*' को https://github.com/component/emitter में जोड़ सकते हैं
साथ ही, वह एमिटर अगले सॉकेट को पावर देने वाला है। इसमें off शॉर्टकट removeListener जो अच्छा है :D

ओह कमाल!

+1

++

+1

+1

+1

+1

+1

+1

+1

+1

+1

क्या किसी ने अभी तक इस दिशा में काम किया है? किसी तरह का निशान?

मेरे पास एक _sort of_ समाधान है जो उन उद्देश्यों के लिए पर्याप्त रूप से काम करता है जिनके लिए हमें इसकी आवश्यकता है, लेकिन यह पूर्ण विकसित वाइल्डकार्ड समाधान नहीं है ... '*' के कार्यान्वयन की तरह

https://github.com/Attorney-Fee/socket.io

+1

+1

+1

+1

+1

+1

मुझे एक ऐसी टिप्पणी छोड़ने से नफरत है जो कुछ भी सार्थक योगदान नहीं देती है, लेकिन अब 2 साल के लिए इसका अनुरोध किया गया है, और सब कुछ रचनात्मक पहले ही कहा जा चुका है। इसलिए...

+1

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

इसे यूजरलैंड में कैसे लागू किया जाएगा? मैंने जो भी समाधान देखे हैं उनमें कोडबेस को फोर्क करना शामिल है, और कुछ लोगों ने अलग-अलग पुस्तकालयों से पूरी तरह से जुड़ा हुआ है।

मेरे मामले में मुझे केवल एक सादा और सरल "एक समारोह में पूरी तरह से सब कुछ पकड़ने" की आवश्यकता है, लेकिन RegEx समर्थन प्रतीत नहीं होता है (उस व्यक्ति को जिसने स्रोत को बहुत करीब से नहीं देखा है) बहुत मुश्किल है, और निश्चित रूप से अविश्वसनीय रूप से उपयोगी होगा . मैं अपने Express.JS रूट्स में हर समय रेगुलर एक्सप्रेशन का उपयोग करता हूं; सॉकेट में ऐसा करने में सक्षम होना अच्छा होगा।

परिवहन परत/प्रोटोकॉल अपरिवर्तित रहेगा। आप केवल नक्शा देखने के लिए नहीं बल्कि एक अधिक व्यापक (regexp आधारित) खोज करने के लिए दोनों सिरों पर 'उत्सर्जन' को ओवरराइड करेंगे।

त्वरित कार्यान्वयन सुझाव:

• घटना के नाम में '*' मिलने पर नियमित अभिव्यक्तियों के लिए एक विशेष डेटास्ट्रक्चर बनाए रखने के लिए on को ओवरराइड करें
• पहले फास्ट केस (नियमित नक्शा लुकअप) करने के लिए emit को ओवरराइड करें, फिर '*' श्रोताओं के माध्यम से जाएं और देखें कि वे मेल खाते हैं या नहीं।

जाहिर है इसके लिए कांटे की जरूरत नहीं है। हुक से मेरा मतलब यह है कि हम संभावित रूप से बंदर-पैचिंग की आवश्यकता नहीं होने का समाधान ढूंढ सकते हैं, लेकिन उन 2 पर विचार करना बहुत आसान तरीका है, मैं इसे एक बड़ी समस्या नहीं मानता।

जिज्ञासा से बाहर, क्या हम यूज़रलैंड से सॉकेट.मैनेजर.प्रोटोटाइप.ऑनक्लाइंटमैसेज को ओवरराइड नहीं कर सकते?

मैंने ऐसा किया और ठीक काम किया, नोड में, socket.io मॉड्यूल में कोई बदलाव नहीं किया। बहुत सुंदर नहीं है और टूटने की संभावना है लेकिन कम से कम आप फोर्किंग से बचते हैं।

https://gist.github.com/lmjabreu/5714985

क्या कोई केवल process.EventEmitter = require('eventemitter2').EventEmitter2 पहले कभी जोड़ नहीं सकता था socket.io की आवश्यकता है? ऐसा लगता है कि यह मेरे लिए काम करता है ...

प्रोटोटाइप को खोलना निश्चित रूप से यूजरलैंड फिक्स नहीं है। मैं समझता हूं कि पूर्ण रेगेक्स समर्थन या कुछ भी लागू नहीं करना चाहता लेकिन एक साधारण सॉकेट.ऑन ('*') एक लंबा सफर तय करेगा।

यह टिकट अभी 2 साल पुराना है।

क्‍या इसका समाधान करने की कोई योजना है, क्‍योंकि यह स्‍पष्‍ट रूप से एक उपयोगी विशेषता है?

अगर उत्तर नहीं है, तो मैं इसे स्वयं जोड़ना और जोड़ना चाहता हूं।
लेकिन मैं इसे तभी करना पसंद करूंगा जब इसके बैक अपस्ट्रीम में विलय होने की संभावना हो।

क्या कोई देव कृपया इसका उत्तर दे सकता है?

लगभग सभी टिप्पणियों से सहमत, फैंसी सामान कम बहस का विषय हो सकता है, लेकिन एक कैच-ऑल अच्छा होगा। उपयोगकर्ता इसे स्वयं कर सकते हैं, लेकिन एक पूर्वनिर्धारित प्रक्रिया क्लीनर होगी।

यह शर्म की बात है कि यह मौजूद नहीं है।

यह मौजूद है, किसी ने पहले पोस्ट किया गया लिंक देखें
http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

मैं इसका उपयोग कर रहा हूं, और यह बहुत अच्छा काम करता है :)

+1

क्या मंकी पैचिंग कुछ ऐसा सरल है जो मुझे लगता है, एक बुरे अभ्यास की तरह है, हालांकि, मुझे लगता है कि कोई बड़ा कार्यान्वयन नहीं किया जाना चाहिए, Backbone.Events जैसा कुछ सरल इस मुद्दे में अधिकांश देवों के लिए पर्याप्त होगा, मुझे लगता है। (हालांकि बैकबोन "*" का उपयोग नहीं करता है, लेकिन वैश्विक घटना के लिए "सभी" का उपयोग करता है, मूल रूप से बुलाए जाने वाले ईवेंट नाम में गुजरना, जो कि करने के लिए सबसे अच्छी बात है)। (यह सिर्फ एक सुझाव है, हालांकि) =)

RegExp तरीके से व्यक्तिगत रूप से +1, यह "*" वाइल्डकार्ड की तुलना में अधिक जावास्क्रिप्ट और कम कंसोल महसूस करता है।

लेकिन नवीनतम आवाजों की तरह, कैच-ऑल फ़ंक्शन अधिक उपयुक्त लगता है।

सुनिश्चित नहीं है कि यह वास्तव में एक socket.io समस्या है।

आईएमओ को दोष देने के लिए एक जमे हुए एपीआई।

:+1:

यदि कोई इस धागे को पढ़ता है और अभी भी 0.9.x और 1.0.0 पर वाइल्डकार्ड ईवेंट का उपयोग करने का तरीका ढूंढ रहा है: https://www.npmjs.org/package/socketio-wildcard

अद्भुत @geoah !

@guille हे , यह मेरा नहीं है मैं बस इस पर ठोकर खाई। आप सभी की कड़ी मेहनत के लिए धन्यवाद बीटीडब्ल्यू ^_^

कल रात socket.io के लिए एक मिडलवेयर को व्हिप किया।

https://www.npmjs.org/package/socket.io-events

+1
नए श्रोताओं को बनाने के ऊपरी हिस्से में कटौती करना अच्छा होगा जब डेटा हमेशा एक ही संभाला जाएगा।
@geoah मिडलवेयर के लिए धन्यवाद, वही किया जो मुझे चाहिए था!

यदि मिडलवेयर ठीक काम करता है, तो socket.io को वैसे ही रहना चाहिए।

यह उन चीजों में से एक है जो मुझे व्यक्तिगत रूप से लगता है कि socket.io के हिस्से के रूप में सही समझ में आता है। मैं इसे छोड़ने के लिए कोई तर्क नहीं देखता, सिवाय इसके कि "यहां चीजें इस तरह से नहीं की जाती हैं", जो कभी भी एक बहुत अच्छा तर्क नहीं है।

तर्क यह है कि हम नोड की तरह काम करने की कोशिश करते हैं EventEmitter , और नोड में यह नहीं है, इसलिए यह "socket.io-ism" बन जाएगा। इसे जोड़ने के बारे में Node में व्यापक चर्चा हुई और यह सफल नहीं हुआ।

@chevex जबकि यह मूल रूप से मेरी भावना भी थी, नया मिडलवेयर समर्थन अपने आप में जोड़ना बहुत आसान बनाता है। एक उदाहरण के रूप में सॉकेटियो-वाइल्डकार्ड को देखते हुए, आयात और उपयोग करना आसान है; यह शायद एक्सप्रेस.जेएस की तरह ही समाप्त हो जाएगा जहां मिडलवेयर के कुछ टुकड़े हैं जिन्हें मैं लगभग हमेशा शामिल करता हूं।

वे बहुत बेहतर तर्क हैं। मुझे लगता है कि आप नहीं चाहेंगे कि EventEmitter डिफ़ॉल्ट रूप से नोड से अलग व्यवहार करे। और @ DanH42 मुझे यह भी लगता है कि आप सही कह रहे हैं कि इसे मिडलवेयर के साथ

यदि केवल नोड का EventEmitter बॉक्स से बाहर वाइल्डकार्ड का समर्थन करता है।

:+1:

मैं देख रहा हूं कि मैं इस मुद्दे से चूक गया, मैंने घटनाओं को अग्रेषित करने पर एक नया मुद्दा शुरू किया:
https://github.com/Automattic/socket.io/issues/1715
इसमें स्रोत को बदले बिना सॉकेट.io 1.0 से सभी घटनाओं को संभालने के दो तरीके शामिल हैं।

मैं बस इसे डिबगिंग के लिए चाहता हूं। मेरे पास हमारी परियोजना में पुस्तकालयों को जोड़ने या संशोधित करने का अधिकार नहीं है। : सिसकना:

+1
कभी-कभी, आपको उन सभी घटनाओं को जानना होगा जो प्रचार कर रही हैं!

+1

• 1

मैं hden के सॉकेटियो-वाइल्डकार्ड मॉड्यूल का उपयोग कर समाप्त हुआ; यह सबसे पारदर्शी तरीका लगता है (मिडलवेयर का उपयोग करके) और मेरे लिए काफी अच्छी तरह से काम करता है। लेकिन: +1: इसे कोर में लाने के लिए!

धन्यवाद मैट! मैं बह गया हूं लेकिन मुझे उम्मीद है कि कुछ बनाने के लिए सप्ताहांत होगा
सुधार

मेरे आईफोन से भेजा गया

६ जनवरी २०१५ को सुबह ८:३० बजे मैट फ्लेचर नोटिफिकेशन @github.com ने लिखा:

मैंने @NathanGRomano https://github.com/NathanGRomano 's . का उपयोग करके समाप्त किया
सॉकेटियो-इवेंट्स https://www.npmjs.com/package/socket.io-events मॉड्यूल; यह
सबसे पारदर्शी तरीका लगता है (मिडलवेयर का उपयोग करके) और काफी काम करता है
मेरे लिए अच्छी तरह से। लेकिन [छवि:: +1:] इसे कोर में लाने के लिए!

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/Automattic/socket.io/issues/434#issuecomment -68864750।

+1

+1

++++++

+1 डिबगिंग के लिए उपयोगी होगा।

अगर यह किसी के बस इस पर काम करने की बात है, तो मैं इसे एक शॉट देना चाहता हूं। मुझे सॉकेट.आईओ कोडबेस सीखने के लिए कुछ की आवश्यकता होगी, और मैं शायद ऐसे अन्य कार्यान्वयनों को देखने में कुछ समय बिताऊंगा। रेगेक्स पैटर्न पर आपके क्या विचार हैं? बहुत धीमा? बेशक, मैं अपना समय बर्बाद नहीं करने जा रहा हूं अगर यह ऐसा कुछ नहीं है जिसे विलय के लिए माना जाएगा (मुझे परवाह नहीं है कि मेरा कार्यान्वयन अस्वीकार कर दिया गया है, लेकिन अगर कोई दिलचस्पी नहीं है तो परेशान क्यों है, है ना?) क्या कोई अनुरक्षक कृपया सलाह देगा?

मैंने एक पुस्तकालय लिखा socket.io-events। मैं काम और जरूरत के साथ बह गया हूं
इसे फिर से छूने के लिए। मैं इसके साथ पावती का समर्थन करना चाहता हूं

शनिवार, जुलाई २५, २०१५ को, जॉन मैंको नोटिफिकेशन @github.com ने लिखा:

अगर यह किसी के बस इस पर काम करने की बात है, तो मैं इसे देना चाहता हूँ a
गोली मार दी मुझे सॉकेट.आईओ कोडबेस सीखने के लिए कुछ की आवश्यकता होगी, और मैं शायद
ऐसे अन्य कार्यान्वयनों को देखने में कुछ समय व्यतीत करें। आपकी क्या हैं
रेगेक्स पैटर्न पर विचार? बहुत धीमा? बेशक, मैं अपना बर्बाद नहीं करने जा रहा हूँ
समय अगर यह ऐसा कुछ नहीं है जिसे विलय के लिए माना जाएगा (मैं नहीं
परवाह है अगर मेरा कार्यान्वयन अस्वीकार कर दिया गया है, लेकिन अगर कोई दिलचस्पी नहीं है तो क्यों
परेशान, है ना?) क्या कोई अनुरक्षक कृपया सलाह देगा?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/socketio/socket.io/issues/434#issuecomment -124901706।

+1

+1 यह मुद्दा 5 साल पुराना है। वाइल्डकार्ड सपोर्ट को फिर से क्यों नहीं जोड़ा गया है?

+1

+1

+1

+1

+666

+1

दोस्तों, गंभीरता से। हर कोई यह सुविधा चाहता है- मुझे लगता है कि वे इसे प्राप्त करते हैं। आइए सभी प्लस-वन के साथ रुकें, कृपया? समस्या के साथ कुछ वास्तविक प्रगति होने पर मुझे एक अपडेट ईमेल प्राप्त होगा।

उस ने कहा, यह जानना उपयोगी है कि बहुत से लोग रुचि रखते हैं।
मुझे लगता है कि आदर्श रूप से गिटहब में मतदान प्रणाली होनी चाहिए?

एक मतदान प्रणाली बहुत अच्छी होगी, लेकिन इसके जल्द ही होने की संभावना नहीं है।

मुझे लगता है कि समस्या यह है कि एक समाधान अब कई बार पोस्ट किया गया है, लेकिन सभी +1 टिप्पणियों के कारण स्क्रॉल आउट ऑफ व्यू है।

सॉकेटियो-वाइल्डकार्ड मॉड्यूल मेरे लिए अच्छा काम कर रहा है (बेशक मैंने अभी तक नवीनतम नोड में अपडेट नहीं किया है)।
यह उपयोगी होगा अगर कोई समझा सके कि यह lib उपयुक्त क्यों नहीं है?

हाँ, सॉकेटियो-वाइल्डकार्ड पूरी तरह से अच्छी तरह से काम करता है, लेकिन यह अभी भी एक अतिरिक्त निर्भरता है जो इतना आसान है कि इसे कोर में पेश करना अच्छा होगा और इस पूरे मुद्दे को एक बार और सभी के लिए समाप्त कर दें। साथ ही यह भ्रम की किसी भी जगह को हटा देता है कि कौन सा बाहरी मॉड्यूल उपयोग करने के लिए सबसे अच्छा है (अक्सर इसी तरह नामित)। यह भी सहमत हैं कि यह अच्छा होगा यदि गिटहब में मतदान प्रणाली होती, यदि केवल एक तरीका होता तो हम उस पर मतदान कर सकते थे...!

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

मैं समझता हूं कि अनुरक्षकों को हर प्रस्ताव को स्वीकार करने की आवश्यकता नहीं है, लेकिन यह? यह मुझे पूरी तरह से भ्रमित करता है। जाने के लिए रास्ता।

@ n2liquid यह इतना स्पष्ट नहीं है कि यह मूल में होना चाहिए, लेकिन चर्चा का स्वागत है। उदाहरण के लिए, कोई अन्य नोड घटना उत्सर्जक इस तरह से व्यवहार नहीं करता है, भले ही वहां एक चर्चा भी हुई हो।

@rauchg

यह इतना स्पष्ट नहीं है कि यह मूल में होना चाहिए, लेकिन चर्चा का स्वागत है

क्या तब हम इस बारे में चर्चा कर सकते हैं?

मैं आपकी बात समझ सकता हूं कि नोड दुनिया में इस तरह का एमिटर जरूरी नहीं है, लेकिन यह निर्भर करता है कि आप क्या हासिल करने की कोशिश कर रहे हैं ....
क्या सम्मेलनों का सख्ती से पालन करने या वास्तव में उपयोगी पुस्तकालय प्रदान करने का विचार है?

यह स्पष्ट लगता है कि इस सुविधा के मूल में होने के बिना socket.io के कई उपयोगकर्ता वास्तव में ठोकर खा रहे हैं, और उपयोगकर्ता के लिए यह अपेक्षा करना उचित लगता है कि यह होना चाहिए।

या इसे दूसरे तरीके से रखने के लिए, इस सुविधा को socket.io में प्रदान नहीं करने के लिए क्या तर्क हैं?
यहां तक ​​​​कि अगर कार्यान्वयन 'पाठ्यपुस्तक सही' नहीं है, तो इसके परिणामस्वरूप लोगों को कई अलग-अलग पुस्तकालयों और विधियों का सहारा लेने के बजाय, सॉकेट.आईओ में इन 'कैचॉल' हैंडलर को लागू करने का एक मानक तरीका होगा।
लोगों को किसी तीसरे पक्ष के परिवाद या वर्कअराउंड के लिए निर्देशित करना केवल चीजों को खंडित करता है, और इसे और भी नाजुक बनाता है जो एक कोडबेस को बनाए रखने की कोशिश कर रहा है जो सॉकेट का उपयोग करता है।

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

@rauchg मुझे लगता है कि इसे लागू करने का एक अच्छा तरीका socket.use(function(data,next){..}) फ़ंक्शन होगा जो सॉकेट पर सभी घटनाओं को पकड़ता है, और एक अगला() फ़ंक्शन पास किया जाता है जो कैचॉल से बाद के कैचॉल या डिफ़ॉल्ट ईवेंट हैंडलर पर नियंत्रण पास करता है .

इस प्रकार मैं अभी socket.io का उपयोग कर रहा हूं क्योंकि मुझे प्रति/मिनट में आने वाली घटनाओं की मात्रा को सीमित करने का एक तरीका चाहिए, जो मुझे लगता है कि एक आम उपयोग मामला है। मेरे 2 सेंट पढ़ने के लिए धन्यवाद।

मुझे @ Michael77 का समाधान सबसे अधिक पसंद है। यह इवेंट एमिटर इंटरफेस या कार्यान्वयन को नहीं छूता है और यहां तक ​​​​कि हम यहां पूछ रहे हैं की तुलना में अधिक चीजों की अनुमति देता है (उदाहरण के लिए @ माइकल 77 का संदेश थ्रॉटलिंग कार्यान्वयन और कौन जानता है)।

मुझे पता है कि socket.io में एक मिडलवेयर/उपयोग फ़ंक्शन है, लेकिन यह क्लाइंट लाइब्रेरी पर उपयोग करने योग्य नहीं है, और मुझे यकीन नहीं है कि यह इसी उद्देश्य को पूरा करता है या नहीं।

@carpii _not_ किसी चीज़ का समर्थन करने के लिए हमेशा बहुत अच्छे कारण होते हैं: जटिलता जोड़ना, परिचितता को कम करना। यह सुविधा दोनों की जाँच करती है।

मुझे socket.use विचार बहुत पसंद है, जिसके शीर्ष पर क्लाइंट पर वाइल्डकार्ड एक्सटेंशन को आसानी से लागू किया जा सकता है।

धन्यवाद @carpii @Michael77 @n2liquid इस

@rauchg , मुझे खेद है कि मैंने सॉकेट के बारे में उन बुरी बातों को कहा। मेरा दिन खराब चल रहा था। इस परियोजना के लिए धन्यवाद; यह सही (अभी तक) नहीं हो सकता है, लेकिन यह निश्चित रूप से बहुत उपयोगी है।

इसके अलावा: https://github.com/hden/socketio-wildcard/issues/13

@n2liquid _all_ प्रतिक्रिया का स्वागत है - धन्यवाद (और @hden को socket.io-wildcard पर उस त्वरित सुधार के लिए)।

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

@akotlar यदि आप scoketio-wildcard का उपयोग कर रहे हैं तो ईवेंट का नाम कॉलबैक में उपलब्ध है।

आह, धन्यवाद! इसे socket.io-wildcard readme में निर्दिष्ट करना उपयोगी हो सकता है।

यह कैसा चल रहा है?
क्लाइंट और सर्वर दोनों के लिए on("*", function () { लिए +1

+1 सभी तरह से

@ alexey -sh https://github.com/hden/socketio-wildcard से दस्तावेज़ को पढ़ेंगे, तो हाँ क्लाइंट और सर्वर दोनों के लिए ऐसा करना संभव है।

@hden धन्यवाद और हाँ मैंने इसे देखा और मैं पहले से ही इसका उपयोग कर रहा हूं। लेकिन यह एक अतिरिक्त निर्भरता है और इसे सीधे Socket.IO कोर में एकीकृत करने के खिलाफ कुछ भी नहीं बोलता है, इसलिए इसे मुझसे +1 मिलता है।

इसे सभी ईवेंट के लिए एक ईवेंट नाम का उपयोग करके ऐप लॉजिक में नियंत्रित किया जा सकता है:

socket.emit('public-event', {'type': 'login', ...});
socket.emit('public-event', {'type': 'logout', ...});

+1 भले ही मुद्दा बंद हो।

+💯 धमाका!

+1 !!!!

कृपया socket.use उपयोग करें।

क्या socket.use() का उपयोग करके engine.io के पिंग/पोंग तंत्र में हुक करने का कोई तरीका है?

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

मैं पिंग/पोंग पैकेट लॉग करना चाहता हूं, लेकिन ऐसा लगता है कि सॉकेट। उपयोग() केवल उच्च स्तरीय उपयोगकर्ता-ईवेंट संदेशों में लगा सकता है, न कि इंजन। आईओ के अंतर्निहित प्रोटोकॉल

+1

+1

2011 से +1? वे यह नहीं कर रहे हैं। :(

फिर से, उस मामले के लिए socket.use जोड़ा गया: https://socket.io/docs/server-api/#socket -use-fn

@darrachequesne मैं नहीं देखता कि सर्वर-साइड पर एक विधि इस अनुरोध के साथ कैसे मदद करती है (जो क्लाइंट के लिए है)।

इस पर और? चूँकि socket.use केवल सर्वर के लिए है, यह टिकट क्यों बंद है?

मुझे socket.use समझ नहीं आ रहा है। कैसे बदलें

// Server
io.in('room1').emit('backend', data_out);
io.in('room1').emit('frontend', data_out);

कुछ इस तरह के साथ

// Server
io.in('room1').emit('*end', data_out);  // not working code - proper regex would be nice

या

// Client
socket.on('*end', function(data){  // not working code - proper regex would be nice

एक छोटा समाधान मिला - सभी संभावनाओं को सूचीबद्ध करना:

// Client
var lala = function(data){ 
    // example
}
socket.on('backend', lala);
socket.on('frontend', lala);