MCP, 40 साल की RPC और वितरित सिस्टम सीखों को नजरअंदाज करता है
(medium.com/@julsimon)- MCP (Model Context Protocol) AI टूल इंटीग्रेशन को standardize करने का दावा करता है, लेकिन इसमें 40 वर्षों में विकसित वितरित प्रणालियों और RPC best practices को नज़रअंदाज़ करने की खामी है
- इसके कारण एंटरप्राइज माहौल में ऑपरेशनल विश्वसनीयता, प्रकार सुरक्षा, सुरक्षा, observability और लागत प्रबंधन जैसी मूलभूत क्षमताएँ अनुपस्थित रहती हैं
- MCP आवश्यक फीचर्स को बाहरी लाइब्रेरी पर निर्भर करता है, साथ ही प्रोटोकॉल फ्रैगमेंटेशन और इंटीग्रेशन की जटिलता, तथा audit/security management का अतिरिक्त बोझ बढ़ाता है
- वितरित ट्रेसिंग, स्कीमा संस्करण प्रबंधन, सर्विस डिस्कवरी और performance optimization जैसी मुख्य ऑपरेशनल आवश्यकताएँ अभी भी अधूरी हैं
- MCP को जल्दी अपनाने से AI बूम के भरोसे एंटरप्राइज में गंभीर व्यवधान, ऑपरेशनल जोखिम, दोहराव वाला विकास और अनावश्यक खर्च बढ़ने का खतरा है
MCP की सादगी से उत्पन्न जोखिम
MCP (Model Context Protocol) AI टूल्स के बीच इंटीग्रेशन को “AI दुनिया का USB-C” बता कर अपनी पहचान बनाता है और अपनाने की बाधा को घटाने वाली सरलता पर जोर देता है। लेकिन यही सरलता 40 वर्षों में वितरित प्रणालियों से मिली सीख को नज़रअंदाज़ करती है, जिससे वास्तविक रनटाइम वातावरण में घातक फीचर गैप बनते हैं। MCP अपनाने वाली कंपनियाँ फिलहाल ऐसे आधार पर सिस्टम बना रही हैं जिसमें आवश्यक RPC सिस्टम फीचर्स मूल रूप से मौजूद नहीं होते।
वास्तविकता और अपेक्षा के बीच खतरनाक दूरी
MCP समर्थक इसे production-ready infrastructure के रूप में पेश करते हैं, लेकिन वास्तविक डिज़ाइन विकसित करने में सुविधा (developer convenience) पर झुका है और ऑपरेशनल मज़बूती कमज़ोर है। यह अल्पकाल में AI टूल कनेक्ट करने में मदद करता है, पर जब इसे लाखों requests के स्तर पर असली बिज़नेस में चलाया जाता है तो गंभीर कमी उजागर होती है। AI के प्रति अति-उत्साही बाजार अपेक्षा के कारण आर्किटेक्चरल परिपक्वता के बिना जल्दी अपनाव बढ़ रहा है, और इससे ऑपरेशनल फेलियर का जोखिम काफी बढ़ जाता है।
40 साल के इतिहास से दोहराए जा रहे गलती के पैटर्न
-
UNIX RPC (1982) में 32-बिट integers जैसी heterogeneous systems के बीच डेटा compatibility के लिए XDR (External Data Representation) और IDL (Interface Definition Language) लाए गए, जिससे build-time पर type mismatch errors पकड़ी जा सकीं।
MCP ने इस अनुभव को नजरअंदाज कर केवल schema-less JSON और गैर-बाध्यकारी hints देता है। रनटाइम में type errors हो सकते हैं, और AI गलत तारीखें बना सकता है, जिससे finance, healthcare और manufacturing जैसे वास्तविक उत्पादन क्षेत्रों में गंभीर data-conversion errors और quality issues हो सकते हैं -
CORBA (1991) ने कई भाषाओं में समान interface सुनिश्चित करने के लिए OMG IDL का उपयोग किया। MCP में हर भाषा अलग-अलग तरीके से implement होती है, इसलिए serialization और error handling में भाषा/लाइब्रेरी दर भाषा consistency नहीं रहती, जिससे integration का दुखद सपना बनता है।
-
REST (2000) ने stateless architecture, verb आधारित meaning clarity और cache headers से बड़ी scale और reliability पाई।
MCP में stateful/stateless विभाजन अस्पष्ट है, और इसमें cache, standardized request semantics तथा idempotency support नहीं है। परिणामस्वरूप server scaling, retry और load balancing बेहद कठिन हो जाते हैं। -
SOAP/WSDL ने machine-readable contract, automation capability और security extensibility उपलब्ध कराए।
MCP सिर्फ सरल JSON schema देता है, जबकि machine-readable contract, auto generation, type safety और security audit जैसी चीज़ें मौजूद नहीं हैं। OAuth 2.1 भी बाद में सिर्फ HTTP transport में जोड़ा गया, जबकि stdio अभी भी environment variables पर निर्भर है; इसलिए security controls भी कमजोर हैं। -
gRPC (2016) में observability, distributed tracing, bidirectional streaming, deadlines, structured error codes पहले से ही मौजूद हैं।
MCP केवल event-based एक-दिशीय streaming देता है, जिससे जटिल interaction को efficiently implement करना कठिन होता है। इसमें tracing context, deadlines, error taxonomy जैसी ज़रूरी चीज़ें नहीं हैं।
“बस यह लाइब्रेरी इस्तेमाल करें” वाला जोखिम
MCP हर बार किसी गंभीर flaw के उठने पर तीसरी-पक्ष लाइब्रेरी जोड़ने को जवाब के तौर पर पेश करता है (जैसे mcp-oauth-wrapper, mcp-tracing-extension, mcp-schema-generator)। लेकिन ये जवाब दरअसल प्रोटोकॉल की मूल विफलता को छुपाते हैं। जब मुख्य फीचर बाहर बाँट दिए जाते हैं, तो fragmentation, inconsistency, maintenance/security/integration responsibility का बोझ बढ़ता है।
एंटरप्राइज में कुछ महीनों के भीतर ही standardization, audit और integration का भार बढ़ जाता है, जबकि developer training और बाहरी dependencies असामान्य रूप से ऊँची हो जाती हैं।
बढ़ते जा रहे अस्थायी patch
MCP का 2025–03–26 संस्करण लगभग ऐसा लगता है जैसे production में बाद में खोजे गए bugs को जोड़-तोड़ कर patch notes से सुधारा गया हो। OAuth, session management, tool properties (annotation), progress status notifications आदि सब वास्तव में शुरुआत से ही जरूरी फीचर थे, जिन्हें बाद में जोड़ा गया।
tool property distinction भी शुरुआती चरण में मौजूद नहीं था, सुरक्षा प्रमाणीकरण को भी पहले गैर-जरूरी माना गया। यह एंटरप्राइज जरूरतों की बुनियादी समझ की कमी दिखाता है।
debugging का दुःस्वप्न और ऑपरेशनल ट्रैकिंग का अभाव
gRPC में distributed tracing और trace IDs की मदद से तेज़ और consistent debugging संभव है।
इसके उलट MCP में request-to-request correlation IDs नहीं, log format mismatch और अतिरिक्त custom implementation की जरूरत होने से debugging और error tracing में कई दिन लग सकते हैं।
ऑपरेशनल और बिज़नेस दोनों नज़रियों से cost allocation और usage management (header, token counting, quota आदि) संभव नहीं है।
क्लाउड माहौल में मूलभूत सुविधाएँ MCP में उपलब्ध ही नहीं हैं, इसलिए AI खर्च और जवाबदेही का ट्रैक लगभग असंभव हो जाता है।
अभी तक बाकी मुख्य ऑपरेशनल समस्याएँ
- सर्विस डिस्कवरी की कमी से availability, multi-region scale-out और zero-downtime rollout संभव नहीं है
- टूल-स्तरीय schema version management की कमी से tool update होने पर पूरी client population अचानक break हो सकती है
- performance limitations: JSON overhead, connection pooling का अभाव, binary protocol/compression का समर्थन सीमित, process-level communication pattern जैसी पुराने style की पुनरावृत्ति
एंटरप्राइज उपयोग में गंभीर जोखिम
जब AI वास्तविक revenue, safety और quality वाले क्षेत्रों (finance, healthcare, manufacturing, customer support आदि) में प्रवेश करता है, MCP अपनाने का जोखिम और बढ़ जाता है।
लंबे समय में बने हुए मजबूत integration patterns को छोड़कर security, audit, type safety, operational stability को बाद में patch करने की कोशिश की जाती है।
"जल्दी बनाओ और गिराओ" वाला proof-of-concept दृष्टिकोण महत्वपूर्ण सेवाओं पर लागू करना घातक परिणाम दे सकता है।
सुधार की दिशा और दीर्घकालिक अपेक्षाएँ
- अल्पकाल: protocol स्तर पर ही type safety, distributed tracing (correlation ID), authorization, standardized audit format, और tool-level independent schema version management को अनिवार्य करना
- ऑपरेशनल पक्ष: service discovery, connection pooling, binary transport, deadlines, तथा standardized error/retry policies की मांग
- दीर्घकाल: bidirectional streaming, in-built quota/cost management, SLA enforcement, workflow orchestration जैसी enterprise-grade सुविधाएँ
निष्कर्ष
MCP की simplicity-driven design प्रयोगात्मक और छोटे चक्र वाले AI टूल integration के लिए तो ठीक हो सकती है, लेकिन एंटरप्राइज-ग्रेड ऑपरेशन्स में यह घातक रूप से ऑपरेशन रिस्क और ऑपरेशनल लागत बढ़ा देती है।
AI बूम के साथ-साथ तेजी से अपनाव बढ़ रहा है, और security, observability, ऑपरेशनल stability जैसे आवश्यक फीचर बाद में patch करने की अस्थायी संस्कृति दोहराई जा रही है।
अंततः, जिस fragmentation और duplicate development से MCP बचना चाहता था, वही इसमें पुनः उभरने का जोखिम है।
AI उद्योग इस मोड़ पर है: क्या वह 40 वर्षों की distributed systems यात्रा से सीख लेकर आगे बढ़ेगा, या फिर पहले ही हल हो चुके मुद्दों को दोबारा झेलेगा?
यदि यही चलता रहा, तो फेल होने वाले adoption, security flaws, और ऑपरेशनल nightmare दोहराएंगे, और इनकी पूरी लागत एंटरप्राइज को ही वहन करनी पड़ेगी।
1 टिप्पणियां
Hacker News की टिप्पणियाँ
शुरुआत में जब सिर्फ शीर्षक देखा तो लगा था कि शायद यह एक typical security-shaming वाली कहानी है। लेकिन पढ़ने के बाद सच में लगा कि इसमें काफी deep insight है। खासकर यह लाइन: MCP शायद इन lessons को ignore करके schema-विहीन JSON में non-enforced hints इस्तेमाल करता है, जहां type validation रनटाइम में होती है या कई बार होती ही नहीं। उदाहरण के लिए, अगर कोई AI टूल ISO-8601 timestamp अपेक्षा करे और उसे Unix epoch value मिल जाए, तो मॉडल ठीक से fail नहीं करेगा बल्कि कोई भी तारीख generate कर देगा। फाइनेंस में ऐसा हो तो trading AI नंबर गलत समझकर गलत decimal precision के साथ trade execute कर सकता है; healthcare में patient डेटा का गलत type conversion गलत दवा की मात्रा की recommendation दे सकता है। manufacturing में sensor डेटा JSON serialization के दौरान precision खो सकता है और quality issues पैदा हो सकते हैं। मैं जो रोज़ LLMs के साथ काम करता हूँ, ऐसा issue असल दुनिया में बार-बार दिखता है। आगे चलकर MCP वाला कोई भी सिस्टम कहीं बड़ा incident face करेगा, और postmortem में दिखेगा कि MCP server ने खराब डेटा emit किया, उसे LLM ने उठा कर गलत hallucinated output दे दी, और उसका असर chain की तरह बढ़ते-बढ़ते बड़े मामलों में बदल गया। Human error, बिना exception handling वाली LLM की nature (hallucination) और startups का जल्दी-जल्दी नई services launch करने का culture—ये सब मिलकर नया class of bugs बना देगा। और जब ये बाहर आएगा तो Twitter users बस यही चिल्लाएँगे कि AGI ने missile launch code hack कर लिया; वो scene शायद काफी fascinating होगा।
सच कहूँ तो 2023 से पहले मुझे लगता था कि Star Trek में दिखने वाले technical bugs इतने fictional हैं कि real life में नहीं होंगे। लेकिन LLM आने के बाद ऐसा लगता है कि अब ये निश्चित ही हो सकता है। LLM integration का engineering से क्या रिश्ता रह गया? और पूरी कंपनी का infra बाहरी control पर छोड़ना कितना logical है, समझ नहीं आता। ऊपर से reproducibility की कमी जोड़ें तो सिर्फ “चल ही रहा है” को engineering नहीं कहा जा सकता।
लेखक की आलोचना ठीक से समझ नहीं आई। MCP JSON Schema support करता है और server response को वही schema follow करना होता है। अगर ISO-8601 timestamp चाहने वाला schema हो और server Unix epoch भेज दे, तो यह साफ protocol violation है। पोस्ट में MCP JSON Schema को support करने के बावजूद type-safe client नहीं बना सकता कहा गया, जबकि पहले से ही बहुत सारे JSON Schema code generators मौजूद हैं—ये तथ्य से अलग है।
PEBKAC पहले से मौजूद है; LLM तो उसे लगभग automate कर देता है।
healthcare में गलत डेटा type conversion से prescription गलत होने की बात पर, मैं जब medical telemetry करता था तब timestamp सही parse करने का कितना importance होता है, खुद महसूस किया। शायद इसलिए unit tests लिखना शुरू किए थे। बिना NTP के हमने header timestamp को वापस calculate करके normalize भी किया था। ऐसी हर चीज़ का कारण accident review और medical negligence liability था। उदाहरण के लिए, patient को cardiac arrest से ठीक पहले दवा मिलने और बाद में मिलने का समय अगर पलट जाए तो ज़िंदगी का फर्क पड़ता है। हाल ही के UK Post Office केस की तरह एक छोटी data गलती से पूरी ज़िंदगी टूट सकती है; healthcare में तो 1 मिनट का फर्क दुनिया बदल सकता है।
MCP का उद्देश्य transport और context management है। यानी schema definition/validation जैसी reasonable interface implementation responsibility यूज़र की होती है। यह “HTTP json validation नहीं करता” वाली टिप्पणी जैसा ही है—बिल्कुल obvious।
MCP का claim कि यह ‘AI दुनिया का USB-C’ बन जाएगा, विडंबना से ज्यादा USB-C की problems का उदाहरण लगता है। USB-C लगभग सबकुछ connect कर सकता है लेकिन standard पालन बहुत खराब है, बिलकुल MCP के inconsistent JSON parsing या protocol non-compliance जैसा। अलग-अलग प्रकार के USB-C cables की मौजूदगी से बाहर से universal दिखता है, पर अंदर बेहद complex reality छिप जाती है। शायद बेहतर होता कि अलग-अलग APIs/protocols को साफ अलग रखा जाता।
USB-C की समस्या की चरम मिसाल शायद Apple का latest M4 Mac mini में USB-A हटाना था। एक जैसे दिखने वाले port वास्तविकता में अलग performance देते हैं, और यूज़र को ये launch के वक्त नहीं बल्कि बाद में पता चलता है। पहले Apple Silicon desktops/laptops में USB-C देखकर लगभग निश्चित 40Gbps Thunderbolt समझा जाता था, अब कुछ सिर्फ USB3 10Gbps हैं। कौन सा port कौन सा है यह spec देखे बिना या छोटे icon देखे बिना नहीं पता चलता। अगर कुछ USB-A छोड़ दिए होते तो 10Gbps की सीमा सीधे दिख जाती; उल्टे USB-C का brand value और dilute हो गया। आखिर अधिकतर USB-C devices भी adapter से USB-A पर चल रहे हैं, USB-C versions महंगे, कम सामान्य और कई बार quality में भी खराब हैं। लेकिन hype और fan following practicality और usability पर भारी है।
सच में उस लाइन (USB-C = universal है पर असल में opaque) पर मैं खूब हँसा। लक्ष्य शायद लगभग achieve हो गया।
SOAP के बारे में यह सुनने में आया कि “जटिल जरूर है लेकिन MCP से कुछ ऐसा समझता है”। सच यह है कि SOAP को भी किसी ने ठीक से नहीं समझा। मैं खुद कई legacy SOAP systems maintain करता हूँ और SOAP के बारे में कोई अच्छी लाइन देने का मन नहीं होता। किसी का रोल मॉडल बनने वाली चीज़ नहीं है।
SOAP वास्तव में massive disaster था। simple concept को कितने absurd तरीके से जटिल बना दिया गया, समझ नहीं आता। XML खुद जटिल था, XML Schema, WSDL या multi HTTP parts जैसी अस्पष्ट परिभाषाएँ थीं, अलग languages की interoperability भी भरोसेमंद नहीं (जैसे .NET server और Java client के साथ SOAP के अनुभव में)। ट्रेंड जब पुराने हो जाते हैं लोग सिर्फ अच्छे पहलू याद रखते हैं, लेकिन मैं होता तो एक महीने SOAP का काम करने की बजाय 50 साल बिना schema JSON API काम करता। व्यक्तिगत तौर पर protobuf और capnp मुझे कहीं बेहतर लगते हैं।
मेरी नज़र में REST (असल में JSON-RPC) या GraphQL अभी भी SOAP और SOA ने जो features देनी थीं, उन्हें पकड़ने की कोशिश कर रहे हैं। हर बार नया tech आने पर अच्छा हिस्सा भी साथ में discard हो जाता है, यह अफ़सोस की बात है।
किसी protocol में “Simple” शब्द आ जाए तो वह अक्सर simple नहीं होता। अब जल्द ही शायद SMCP जैसी कोई चीज़ देखें।
SOAP को बहुत मज़ेदार और सही तरीके से explain करने वाला लिंक शेयर कर रहा हूँ https://harmful.cat-v.org/software/xml/soap/simple। मैं XML-based tech काफी पसंद करता हूँ; खासकर XML Schema की type composition और validation शक्ति अभी भी unmatched लगती है। लेकिन SOAP एक अनावश्यक giant बन गया। सिर्फ simple remote invocation spec चाहिए थी, लेकिन वह पूरी तरह ऐसा spec बन गया जो सब कुछ define करता गया और कुछ सही handle नहीं कर पाया। SOAP कई transport protocol support करने की claim करता है (यहाँ तक कि SOAP over email तक), कई प्रकार के RPC, UDDI आदि self-described RPC विकल्प देता है, लेकिन वास्तविक implementation में auth, caching, HTTP response code जैसी चीज़ें उपयोगकर्ता पर छोड़ दी गईं।
विडंबना यह कि SOAP को स्थायी रूप से reject करने वाला मेरा अनुभव वही SOAP तकनीकी presentation था। समान भाषा में ठीक-ठाक चल जाता था, लेकिन भाषा बदलते ही disaster। शायद इसी वजह से Microsoft SOAP का big fan था।
CORBA 1991 में इसलिए आया कि heterogeneous environment में सिर्फ हर भाषा के लिए अलग protocol implement करना पर्याप्त नहीं—यह insight सही था। OMG IDL अलग भाषाओं के लिए समान bindings बनाकर interface consistency और serialization issues से बचाता था। पर क्या वह सच में सफल उदाहरण था, यह अभी भी सवाल है।
आज का JSON-centric API दुनिया CORBA और SOAP की failures के reaction में दिखी। यानी हमने उनके lesson को भुलाया नहीं, बल्कि intentfully reject किया।
मैंने CORBA को बहुत अच्छे से इस्तेमाल होता हुआ जगह पर काम किया है। शायद टीम में CORBA अनुभव वाले senior engineer की मौजूदगी से ही वह success मिला।
1998 में AT&T के CORBA वाले role के लिए apply किया था; वही आखिरी अनुभव रहा (और उसके बाद मैंने उन्हें सिर्फ JDK download धीमा करने के अलावा नहीं देखा)। उस समय इंटरव्यूअर ने कहा कि मेरा concurrency code उन्हें पसंद नहीं आया, और मैंने प्रतिस्पर्धी स्थिति (race condition) वाला विकल्प पेश किया लेकिन convince नहीं कर पाया। बाद में निष्कर्ष यही निकला कि Java Memory Model कारण मेरा जवाब शायद सही था।
CORBA ने कई चीजें सही कीं, लेकिन यह 80 के आख़िर के traditional telecom network और OOP wave की उपज था। इसलिए इसने network को transparent, reliable और symmetric मान लिया। वास्तविक दुनिया में timeouts, retries, network congestion, system crashes होते हैं, और स्थिति अलग होती है। खासकर CORBA C++ binding, STL के आने से पहले, बहुत खराब थी जबकि अन्य भाषाओं में शायद बेहतर थी।
मैं मानता हूँ कि technically शानदार प्रोजेक्ट भी commercial तौर पर फेल हो सकते हैं, फिर भी उनमें की चमक को पर्याप्त मान्यता देनी चाहिए।
MCP discussion में जो मुख्य lesson छूटता दिखता है, वह यह है कि अधिकतर advanced features complexity बढ़ाते हैं और field में लोग सरल विकल्प चुनते हैं। शायद इसी वजह से JSON over HTTP लोकप्रिय हुआ। बड़ी टेक कंपनियाँ भी gRPC जैसी high-feature serialization protocol पर migration में सालों लगा देती हैं और बीच में कई बार fail हो जाती हैं। MCP का real role शायद सिर्फ JSON API contract को standardize करके LLM के लिए token या tool-calling style generation को आसान बनाना है।
MCP perfect नहीं, मगर उसने दशकों पुराने RPC history से यही ठीक lesson सीखा कि complexity adoption और usage दोनों को कठिन बनाती है (XML की तुलना में JSON का rise)। SOAP interop देने की कोशिश में बहुत complex और XML-schema दोनों बहुत verbose थे। CORBA की libraries और frameworks जटिल थीं, इसलिए उस समय की modern languages में अक्सर avoid किया जाता था। gRPC तेज़ है पर readability कम और mapping जरूरी। आजकल RPC का backbone REST और JSON है। ऊपर के standards धकेले गए या शायद gRPC केवल extreme high-performance needs में सीमित रह गया। REST और JSON के mainstream बनने के पीछे यही simplicity की जीत है, और MCP इसी trend में बना परिणाम है।
बहुत सारे अच्छे points थे। मुझे लगता है हम MCP को गलत समझ रहे हैं। ज्यादा महत्वपूर्ण यह है कि पूरे industry में agent क्या है और आगे क्या होने वाला है, इस बारे में गलतफहमी और direction mismatch है। कई web platforms मानते हैं कि agents को network distributed infra में चिपकना चाहिए, इसलिए container के हर agent को MCP पर service mesh में attach करने का goal रखते हैं। मेरी राय में web-centric तरीके से ‘web-native agent और SDK/frameworks को server application की तरह deploy करना’ गलत है; वे agent नहीं हैं और evolution में शुरूआती form भी नहीं। वास्तविक agent harness शायद Frontier labs जैसी कुछ providers ही बना पाएँगे, और धीरे-धीरे personalization (जैसे मेरे desktop पर Claude Desktop के लिए एक MCP server) की ओर जाएगा। MCP server मूल रूप से इसी single-instance aur harness उपयोग के लिए बने हैं।
काश कोई साफ बताए कि MCP क्यों जरूरी है जबकि Swagger या proto मौजूद हैं।
OpenAPI (Swagger) या Proto (protobuf) MCP की पूरी भूमिका cover नहीं कर पाते। सैद्धांतिक रूप से इनके ऊपर MCP लगाना संभव था, लेकिन MCP के local use-case में Swagger की communication assumptions fit नहीं होतीं, और protobuf में communication protocol include नहीं होता इसलिए अतिरिक्त design की जरूरत पड़ेगी। JSON-RPC बदलने पर भी लगभग पूरी MCP spec को maintain करना पड़ेगा, जिससे complexity बढ़ेगी।
MCP नया tech है
MCP streaming responses support करता है। Polling या session state से भी implement हो सकता है, पर वह बहुत inefficient workaround ही होगा।
OpenAI ने अगर पिछले महीने API use पर $50,000 bill किया हो और यह पता नहीं चल पा रहा हो कि कौन से department के MCP tools ने खर्च बढ़ाया, कौन-सा individual tool call, कौन-सा user, कौन-सा use case था—तो यह दिखाता है कि अधिकांश AI techs पहले समस्याओं के बाद पकड़ी जाती हैं। लेकिन web framework और blockchain की तरह, जब tech बहुत बड़ी होती है तो शुरू में सब कुछ तुरंत नहीं समझ आता। यह gap धीरे-धीरे कम होता है। AI में भी ideas और alertness साझा करना जारी रखना जरूरी है; सच में exciting era है यह।
बेहतर design और पर्याप्त रूप से ठीक design में चयन की स्थिति आती है तो अक्सर पर्याप्त ठीक ही जीतता है। Multics vs Unix, XML-based SOAP vs JSON-based REST, XHTML की विफलता, खुद JavaScript—बहुत उदाहरण दिए जा सकते हैं। इसलिए इंसान हर बार “good enough” को फिर से बनाता है, और issue आते ही patchwork से काम चलाता है।
यह तो well-known Worse is Better pattern का दोहराव है (https://en.m.wikipedia.org/wiki/Worse_is_better). समय के साथ यह कई बार prove हुआ है। मैं भी हमेशा “better” solution की तरफ खिंचता हूँ, मगर real world हमेशा ऐसा नहीं।
xforms 2.0 के लिए 1 मिनट का मौन रखना ज़रूरी लगता है। शायद वह दुनिया होती जो हम जी सकते थे: सही काम करने वाला web form validation, microdata...