How XML-RPC started up - CourtneyR.dev's 2nd Brain

How XML-RPC started up 🔗 **Source:** [How XML-RPC started up](https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html) > [!note]+ Document Notes > tags: [xml-rpc, web-standards, microsoft] > author: scripting.com > source: scripting.com > reference: [https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html] > date created: 2026-01-18 00:00 > > # 🏷️ Title: How XML-RPC started up >  ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. --- ## 📝 Summary - What happened: The author recounts the 1998 creation of XML-RPC as a simple web-based remote procedure call protocol, the early collaboration and friction with Microsoft, and how it later morphed into SOAP and W3C standardization efforts that lost the original simplicity. - Why it matters: The story is framed as a cautionary tale for 2026, where a similar inflection point is emerging around new tech (implicitly AI/web), warning against over-complex, corporate-driven standards and urging simple, developer-focused web infrastructure. - Key stakeholders: Independent developers, big vendors like Microsoft and Apple, standards bodies (W3C), and today’s web/AI ecosystem participants. - Risks and tradeoffs: Simple, working tech can be derailed when large companies and standards processes try to accommodate every use case; the web’s open potential can be constrained by corporate strategy and complexity. - Bottom line: XML-RPC shows how small, independent efforts can successfully seed important infrastructure, but only if the community builds real apps on simple primitives and resists being captured by heavyweight, corporate-led standardization. --- ## 📖 Main Content - Core arguments: - XML-RPC emerged in 1998 from a concrete integration problem: getting Mac and Windows systems to talk over incompatible networking stacks. The author realized that combining HTTP transport with XML payloads could form a universal, firewall-friendly RPC layer: “HTTP plus XML equals RPC.” - Frontier, the author’s scripting environment, already had strong networking; XML-RPC became a minimal, understandable abstraction: everything is just a remote function call. This contrasted with Microsoft engineers’ preference for object- and class-heavy designs with extensibility. - An early collaboration with Microsoft engineers in Redmond—facilitated because Bill Gates regularly read and circulated the author’s blog posts—never fully materialized. Despite initial meetings and an example implementation, Microsoft went silent after the author documented the design. - Acting independently, the author published XML-RPC without Microsoft co-authors, implemented a reference server in Frontier, and evangelized via his widely read blog, positioning XML-RPC as a simple, working protocol. - Inside Microsoft, similar ideas resurfaced and evolved into SOAP, which then entered the W3C standards process. At a large W3C meeting, the author witnessed how big-company requirements and full-time standards staff pushed the specification toward maximal complexity rather than minimal sufficiency. - The author argues that XML-RPC “did” yield something useful, whereas the W3C SOAP process did not, because large, complicated companies cannot keep ideas simple; they must accommodate every legacy and internal requirement. - He reflects that it would have been better to skip the W3C meetings, build real applications on top of XML-RPC, and only then convene developers to decide the next steps based on actual usage. - The essay concludes with a warning for today: when you ask “what can go wrong?” you’re limited by your imagination; the web works best when it follows its own grain, with companies adapting to open, user- and developer-centric infrastructure rather than steering it. - Context and definitions: - XML-RPC: A simple protocol where function calls and responses are encoded in XML and transported over HTTP, enabling cross-platform interop without custom networking stacks. - RPC (Remote Procedure Call): A programming model where calling code invokes functions on remote servers as if they were local functions. - SOAP/W3C: SOAP is a more complex XML-based messaging protocol; W3C is the World Wide Web Consortium, the main web standards body. The author presents SOAP+W3C as the corporate/standards “capture” of a simpler idea. - Uncertainties/contested points: - The evaluation that the W3C process “didn’t yield anything useful” is a strong, opinionated claim; many enterprise systems did use SOAP. The article is explicit about being a personal recollection, and the author notes his memory was imperfect and hurried for the podcast. - Attribution of credit between the author and Microsoft engineers is acknowledged as ethically gray; he notes feeling conflicted about publishing XML-RPC without their names. --- ### 🗒️ Notes - The piece begins with meta-commentary: the show notes were drafted by Claude.ai and may contain mistakes; listeners must hear the podcast for the exact views. The author notes the AI wrote in first person, which he would have preferred to be third person, and appends his own corrections. - Motivation and historical context: - In 1998, the author’s company had built Frontier, “a comprehensive scripting environment with object database, editor, debugger, and extensive verb set” that provided “one unified way to do things instead of JavaScript's fifty million ways,” and had strong networking and desktop publishing integration. - Apple, whose platform Frontier originally targeted, “felt threatened” and put up political/organizational roadblocks. The author describes Apple as having “a lot of bad stuff happening,” and his project as one of the casualties, forcing a move from Mac to Windows. - Problem definition: - The core technical problem: reliable communication between Mac and Windows systems with incompatible networking stacks. - Insight: Use ubiquitous web infrastructure as the bridge—HTTP transport plus XML as a neutral, parseable encoding—leading to the realization encapsulated as “HTTP plus XML equals RPC.” - Microsoft engagement: - After the author blogged the idea, Bob Atkinson from Microsoft called; Bill Gates was a regular reader of the author’s blog and would forward posts internally with “What do you think?” queries, keeping Microsoft leadership informed of the author’s work. - A meeting at Microsoft Redmond was arranged with Bob and another experienced programmer. These were highly valued engineers who wanted to stay on the technical track rather than move into management. - The author emphasizes a “spoiler”: it is easier for an independent developer to push through a new protocol than for senior engineers within a large company, even if they are well-compensated and have big titles. Organizational friction blocks simple, cross-cutting innovations. - He draws a parallel to Apple, where a senior executive wanted a scripting environment but could not get Apple engineers to build it; once they heard of the external initiative, they obstructed it. Takeaway: incumbent developers can “hold back progress” when threatened. - Design debate: functions vs objects: - Don Box, another independent developer, joins the one- or two-day design session at Microsoft. - They brainstorm and sketch; Microsoft sends an example. The author scrutinizes “every detail” and pushes back over calls. - Philosophical divide: - Author: favors RPC semantics—simple function calls—because every programmer understands function calls and “everything is a function call if you go deep enough to machine language.” - Microsoft engineers: want objects, classes, and built-in extensibility, reflecting an enterprise, object-oriented worldview. - The author accepts the push for objects (“let’s go for it”) but immediately documents the resulting spec and shares it with the other three participants. He receives no replies, “complete silence,” despite follow-ups. - Publication and aftermath: - Feeling conflicted about shared intellectual contribution, the author publishes XML-RPC under his name alone, while acknowledging internally that it was not entirely his creation. - His team builds the reference implementation in Frontier, hosts a public test server, and actively evangelizes via his popular blog, driving adoption. - Within Microsoft, similar work evolves into SOAP, which then becomes the basis for a W3C standardization effort. At the first W3C SOAP meeting, about 100 people attend—full-time standards staff and major vendors ensuring representation. - Critique of standards process: - The author claims XML-RPC, as originally defined and implemented, “yielded something useful,” while the W3C SOAP process did not, because: - Large, complex organizations needed to support many legacy systems and internal agendas. - This drove the spec toward maximal accommodation and complexity, away from a minimal solution. - The dynamic exemplifies “bringing what was wrong with the tech industry to the web.” - He argues that a better path would have been: - Ship simple XML-RPC. - Build real applications first. - Convene a developer-only meeting a year later to decide next steps informed by practical experience, not preemptive requirements from large vendors. - Reflection and present-day warning: - The author notes he made “one big mistake” in his earlier telling but corrected it quickly: he misnamed the original blog post; the correct phrase was “RPC over HTTP via XML.” - He states he understood Microsoft’s internal SOAP process “very soon after XML-RPC was released” and explains it as an attempt to recreate the existing networking world and bridge competing approaches. - He laments that XML-RPC was “a seed” whose potential Microsoft “fully understood” but never built on. - Drawing a parallel between 1998 and 2026, he suggests we are again at a moment where the web’s potential could be reshaped. As with podcasting, the web can win when: - We “follow the grain of the web” instead of corporate strategies. - We “work for all developers, not just ones at big corporations.” - We empower users; otherwise, “you don't do it.” - The explicit warning: when you ask “what can go wrong?” absence of imagination is not evidence of safety; unanticipated problems can still exist. - Meta note: the author says he sounds “really tense” in the podcast, rushed for time and relying on imperfect memory rather than thorough research in his 1998 blog posts. --- ## 📚 References - “How XML-RPC started up” (original article): https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html - Historical XML-RPC spec and docs (background, not cited but relevant): http://xmlrpc.com/spec - W3C SOAP (context for later standardization): https://www.w3.org/TR/soap/ --- ## 🗣️ Paraphrase - Paragraph A paraphrase: In the late 1990s, facing broken interoperability between Mac and Windows, the author leveraged HTTP and XML to design XML-RPC—a minimal, function-call style protocol exposed over the web. Early collaboration with Microsoft engineers stalled, so he independently published the spec, shipped a reference implementation, and evangelized it via his blog. - Paragraph B paraphrase: Over time, Microsoft reworked the ideas into SOAP and took them to W3C, where complexity and corporate agendas diluted the original simplicity. The author argues that XML-RPC’s lean, working design delivered more practical value than the heavy standards process and warns that today’s web and AI inflection point should prioritize simple, open, developer-centric infrastructure over corporate strategy. --- ## 📰 Newsletter In today’s history-nerd corner, we’re rewinding to 1998 and the birth of XML-RPC—the humble, HTTP-over-XML workhorse that quietly paved the way for a lot of early remote publishing (including WordPress’s own XML-RPC endpoint). This origin story is a useful mirror for 2026: a simple, developer-driven protocol gets pulled into corporate and standards gravity wells, grows more complex, and loses its original elegance. Sound familiar? For WordPress folks, a few takeaways: - Simple, boring HTTP APIs age better than heavyweight abstractions. - Independent developers can (and do) seed the infrastructure large platforms rely on. - The web works best when we build real apps first, then standardize from experience—not the other way around. If you’re interested in how this connects to modern WordPress APIs: - Revisit the [REST API Handbook](https://developer.wordpress.org/rest-api/). - Compare it with legacy [XML-RPC support](https://developer.wordpress.org/xml-rpc/) and how clients still rely on it. - Think about what today’s “XML-RPC moment” might be for AI + WordPress: lightweight, open primitives that anyone can build on, before big vendors freeze the stack. --- ## ✅ Action Items #### DevRel - Developer advocacy: - Prepare a talk: “From XML-RPC to WP REST API: Lessons from Simple Protocols” for WordCamps and meetups. - Create a short demo showing a client talking to WordPress via both XML-RPC and REST, highlighting tradeoffs. - Education: - Design a workshop on “Designing Small, Stable Web APIs” using XML-RPC history as a case study. - Add a curriculum module on “standards vs. shipping” to internal onboarding for developer advocates. - Developer experience: - Produce code samples that show how to call WordPress APIs with as few abstractions as possible (plain HTTP examples). - Audit SDKs and quickstarts for unnecessary complexity that echoes SOAP-style over-engineering. - Developer marketing: - Run a content series: “Under the Hood: The Simple Protocols Powering WordPress,” referencing XML-RPC as a historical anchor. - Track engagement with posts that emphasize simplicity and longevity of APIs. - Community management: - Host a discussion thread on “What should remain simple in the WordPress stack?” and collect feedback. - Use insights to influence contributor priorities around REST API and future AI integrations. - Internal/external/cross-project: - Align with browser, hosting, and client-app partners on keeping integration points simple and HTTP-first. - Set up a feedback loop from plugin and app developers on API friction points. #### OSPO - Policy & Governance: - Draft guidance that favors small, composable protocols over large, monolithic frameworks for new open standards. - Clarify decision rights for when the org participates in heavy standards bodies versus shipping de facto protocols. - License Compliance: - Ensure any XML-RPC-related or legacy interop libraries used in-house are properly tracked and compliant. - Schedule periodic scans for RPC/interop dependencies in critical paths. - Security Management: - Review historical XML-RPC and SOAP-era vulnerabilities as cautionary examples in security training. - Define clear policies for exposing remote procedure endpoints (rate limits, auth, logging). - Software Inventory: - Maintain an inventory of all RPC-like endpoints (XML-RPC, REST, GraphQL) across products. - Set freshness SLOs for documentation and SBOMs related to these endpoints. - Developer Support: - Offer consultation hours for teams designing new APIs, pushing them toward simple, HTTP-native interfaces. - Provide patterns and threat models that avoid SOAP-style complexity. - Community Engagement: - Support upstream projects that keep core web plumbing simple and interoperable. - Consider MOUs with key open-source projects building HTTP-first protocols. - Strategic Alignment: - Include “simplicity of integration” as a top-level KPI for platform initiatives. - Report to leadership on how standards participation affects time-to-ship and developer happiness. #### Community - Maintainers: - Run roadmap clinics to identify and de-scope overly complex API designs. - Encourage maintainers to document “minimal viable interoperability” first. - Contributors: - Create “first issue” labels around improving docs for core APIs and simplifying examples. - Pair new contributors with maintainers for small “replace complexity with clarity” refactors. - Sponsors: - Tie sponsorship milestones to improved developer ergonomics and simpler integration paths. - Publish impact reports showing how simplicity correlates with adoption. - Ecosystem: - Coordinate incident drills around API breakage or deprecation, emphasizing stable, minimal contracts. - Practice shared disclosure practices for vulnerabilities in common protocols. #### WordPress - Core: - Prioritize keeping core APIs small, predictable, and well-documented. - Use XML-RPC’s history as a cautionary tale in discussions about new abstraction layers. - Core Performance: - Profile the overhead of protocol layers and serialization formats (XML vs JSON). - Set performance budgets that discourage over-complex middleware. - Core AI: - Define guidelines for AI-related endpoints that favor transparent HTTP+JSON interfaces over opaque services. - Curate evaluation sets that test latency and reliability of new protocol designs. - **Core Program Team:** - Schedule cross-team retros that ask, “Are we accidentally reinventing SOAP?” - Track dependencies between new features and underlying protocol complexity. - Mobile: - Keep mobile app API dependencies limited to stable, minimal endpoints. - Provide offline-friendly sync patterns that don’t require heavy protocol stacks. - Playground: - Offer labs where developers can inspect and replay raw HTTP traffic to WordPress APIs. - Create exercises that show the differences between XML-RPC and REST calls. - Community: - Include a “History of WordPress Interop” talk template in meetup kits. - Encourage discussions on “what we should NOT standardize yet.” - Training: - Build lesson plans on “Simplicity in Web APIs” with XML-RPC as a core case study. - Consider a certification module that evaluates understanding of protocol tradeoffs. - Marketing: - Highlight WordPress’s long commitment to open, simple HTTP APIs. - Tell stories of independent devs who built successful tools on top of WordPress APIs. - Support: - Maintain clear troubleshooting paths for legacy XML-RPC clients vs REST clients. - Document when to use which endpoint and how to migrate. - Design: - Ensure developer tools surface raw requests/responses clearly, not just SDK layers. - Use UX patterns that emphasize the “mental model” of simple requests and responses. - Documentation: - Fill DevHub/HelpHub gaps around protocol history, migration, and best practices. - Favor examples-first patterns that start from plain curl or fetch calls. - Photos: - Curate visuals that show the “layers” of WordPress architecture, including APIs. - Maintain taxonomy that clearly tags protocol- and API-related assets. - TV: - Produce short explainer videos on “How WordPress Talks to the World.” - Ensure captions are accurate for technical terminology. - Polyglots: - Localize API docs and tutorials so non-English-speaking developers can adopt them easily. - Align glossaries around core protocol terminology. - Accessibility: - Ensure API docs are accessible and navigable for assistive technologies. - Provide high-contrast code examples and diagrams. - Meta: - Stabilize .org APIs used by the plugin and theme directories. - Monitor API reliability dashboards and error budgets. - CLI: - Keep WP-CLI commands thin wrappers around HTTP APIs where possible. - Provide scaffolds that encourage simple service designs. - Hosting: - Create host-level checklists that validate API connectivity (XML-RPC, REST). - Encourage sane defaults (no unnecessary blocks on core APIs). - Tide: - Incorporate checks related to misuse or overcomplication of external APIs in plugins. - Provide feedback loops to reduce false positives. - Openverse: - Keep ingestion APIs publicly documented and as simple as possible. - Offer examples for self-hosted and third-party integrations. - Themes: - Encourage theme devs to use lightweight API calls only where necessary. - Provide test matrices that cover key API interactions. - Plugins: - Guide plugin authors toward stable, minimal integration protocols. - Include security liaisons for plugins that expose remote-call surfaces. #### The WPOCC - Programs: - Fund fellowships focused on web protocol literacy and simple API design. - Offer microgrants for tools that demystify HTTP-level interactions. - Projects: - Run governance clinics on “When to Standardize vs. When to Ship.” - Sponsor documentation sprints capturing “lessons from XML-RPC and SOAP.” - Funding experiments: - Pilot matched grants for projects building open, simple AI and data APIs on WordPress. - Publish transparent ledgers showing the impact of protocol-simplifying work. ### FAIR - Technical independence: - Prefer protocols that can be self-hosted and inspected (no opaque dependencies). - Encourage signature checks and provenance for critical API payloads. - Policies and covenants: - Require transparency around vendor influence on any standards WordPress adopts. - Use sunset clauses for experimental APIs that skew too complex. - Productized governance artifacts: - Produce lightweight charters for protocol workgroups. - Maintain scorecards that track simplicity, openness, and adoption. --- ## 🧪 Hypotheses - H1: Simple, function-call style web protocols (like XML-RPC) lead to faster and broader grassroots adoption than complex, object-heavy standards (like SOAP). - H2: Independent developers are more likely than large-company engineers to successfully ship new cross-platform web protocols. - H3: Standards processes dominated by large vendors systematically increase protocol complexity without proportional practical benefit. - H4: Building real applications before standardizing produces better, more durable protocols than designing by committee upfront. - H5: In 2026, web/AI infrastructure that “follows the grain of the web” will see higher long-term usage than corporate-strategy-driven stacks. --- ### 📊 Methodology - Study designs: - Comparative adoption study: Collect historical data on adoption curves of XML-RPC vs SOAP (and later REST) across open-source projects and commercial products. - Organizational case studies: Interview independent developers and big-company engineers who participated in protocol efforts, focusing on decision-making and blockers. - Standards impact analysis: Review W3C archives, mailing lists, and specs to quantify length, feature creep, and complexity growth over time. - Data sources: - Open-source repos (GitHub, SourceForge archives) for protocol usage. - Mailing list archives and meeting notes from XML-RPC, SOAP, and W3C groups. - Product documentation from major platforms that adopted (or rejected) each protocol. - Analyses: - Time-series analysis of adoption vs protocol complexity. - Qualitative coding of interviews around themes: simplicity, politics, shipping pressure. - Comparative evaluation of protocol ergonomics (number of concepts, lines-of-code for “hello world” integration, etc.). --- ### ❓ Questions - How much did SOAP’s complexity actually hinder adoption compared to business and tooling factors? - What governance models best protect simple web protocols from corporate capture? - How can today’s AI and web API designers bake in “simplicity constraints” from the start? - What metrics should standards bodies adopt to guard against over-specification? - How can WordPress and similar ecosystems institutionalize a bias toward small, composable interfaces? --- ### 🔮 Future Research - Systematic histories of web protocols that “stayed small” vs those that ballooned under standardization. - Comparative research on independent protocol innovations vs corporate ones across multiple eras (CGI, RSS, XML-RPC, REST, GraphQL, etc.). - Sociotechnical studies of how blog posts and informal writing (like the author’s) influenced big vendors’ decisions. - Design patterns for “minimum viable interoperability” in emerging AI and data standards. --- ### 💡 Implications - Practice: API designers should default to minimal, understandable HTTP interfaces and resist unnecessary abstraction layers. - Policy: Standards bodies and foundations need guardrails that prioritize implementer experience and real-world deployments over theoretical completeness. - Security: Simpler protocols are often easier to audit and secure; complexity can hide misconfigurations and vulnerabilities. - Education: Curricula should include historical case studies (like XML-RPC vs SOAP) to teach protocol design tradeoffs. - Funding models: Grants and sponsorships can explicitly reward projects that maintain simplicity and openness over time. --- ### 🧠 Learning Styles Assessment - Reading level estimate: - Roughly late high-school to early college level (Flesch–Kincaid style estimate: ~11–12), due to technical terms and historical context. #### 👀 Visual learners - Present: - Mainly text-based narrative; no diagrams or charts. - Improve: - Architecture diagrams showing XML-RPC vs SOAP vs REST. - Timelines of key events from 1998 to the W3C meetings. - Before/after visuals comparing “simple” vs “complex” protocol stacks. #### 🔊 Aural learners - Present: - The article is tied to a podcast episode; the audio is central. - Improve: - A concise 2–5 minute audio recap focused just on the protocol lessons. - Optional TTS version of the written notes. - Speaker notes summarizing each core idea. #### 🗣️ Verbal learners - Present: - Rich narrative, definitions of concepts like RPC, and concrete examples. - Improve: - More explicit glossaries of terms (RPC, SOAP, W3C, Frontier). - Clear analogies (e.g., function calls as “remote buttons”). #### 🧩 Kinesthetic learners - Present: - No interactive components. - Improve: - Hands-on labs: send XML-RPC and REST calls to a sample server. - Step-by-step exercises to implement a trivial XML-RPC endpoint. #### 🧠 Logical learners - Present: - Causal reasoning about how organizational structure affects protocol outcomes. - Implicit timelines and comparisons. - Improve: - Explicit tables comparing XML-RPC, SOAP, and REST on complexity metrics. - Decision trees for “when to standardize vs just ship.” #### 🧑‍🤝‍🧑 Social learners - Present: - Story of collaboration and conflict among individuals and organizations. - Improve: - Discussion prompts for groups (“What would you have done at Microsoft?”). - Moderated Q&A sessions or forums reflecting on lessons learned. #### 🧘‍♀️ Solitary learners - Present: - Self-contained narrative suitable for reflective reading. - Improve: - Reflection questions at the end (“How does this affect your API --- --- tags: [xml-rpc, web-standards, microsoft] author: scripting.com source: scripting.com reference: [https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html] date created: 2026-01-18 00:00 --- # 🏷️ Title: How XML-RPC started up ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. --- ## 📝 Summary - What happened: The author recounts the 1998 creation of XML-RPC as a simple web-based remote procedure call protocol, the early collaboration and friction with Microsoft, and how it later morphed into SOAP and W3C standardization efforts that lost the original simplicity. - Why it matters: The story is framed as a cautionary tale for 2026, where a similar inflection point is emerging around new tech (implicitly AI/web), warning against over-complex, corporate-driven standards and urging simple, developer-focused web infrastructure. - Key stakeholders: Independent developers, big vendors like Microsoft and Apple, standards bodies (W3C), and today’s web/AI ecosystem participants. - Risks and tradeoffs: Simple, working tech can be derailed when large companies and standards processes try to accommodate every use case; the web’s open potential can be constrained by corporate strategy and complexity. - Bottom line: XML-RPC shows how small, independent efforts can successfully seed important infrastructure, but only if the community builds real apps on simple primitives and resists being captured by heavyweight, corporate-led standardization. --- ## 📖 Main Content - Core arguments: - XML-RPC emerged in 1998 from a concrete integration problem: getting Mac and Windows systems to talk over incompatible networking stacks. The author realized that combining HTTP transport with XML payloads could form a universal, firewall-friendly RPC layer: “HTTP plus XML equals RPC.” - Frontier, the author’s scripting environment, already had strong networking; XML-RPC became a minimal, understandable abstraction: everything is just a remote function call. This contrasted with Microsoft engineers’ preference for object- and class-heavy designs with extensibility. - An early collaboration with Microsoft engineers in Redmond—facilitated because Bill Gates regularly read and circulated the author’s blog posts—never fully materialized. Despite initial meetings and an example implementation, Microsoft went silent after the author documented the design. - Acting independently, the author published XML-RPC without Microsoft co-authors, implemented a reference server in Frontier, and evangelized via his widely read blog, positioning XML-RPC as a simple, working protocol. - Inside Microsoft, similar ideas resurfaced and evolved into SOAP, which then entered the W3C standards process. At a large W3C meeting, the author witnessed how big-company requirements and full-time standards staff pushed the specification toward maximal complexity rather than minimal sufficiency. - The author argues that XML-RPC “did” yield something useful, whereas the W3C SOAP process did not, because large, complicated companies cannot keep ideas simple; they must accommodate every legacy and internal requirement. - He reflects that it would have been better to skip the W3C meetings, build real applications on top of XML-RPC, and only then convene developers to decide the next steps based on actual usage. - The essay concludes with a warning for today: when you ask “what can go wrong?” you’re limited by your imagination; the web works best when it follows its own grain, with companies adapting to open, user- and developer-centric infrastructure rather than steering it. - Context and definitions: - XML-RPC: A simple protocol where function calls and responses are encoded in XML and transported over HTTP, enabling cross-platform interop without custom networking stacks. - RPC (Remote Procedure Call): A programming model where calling code invokes functions on remote servers as if they were local functions. - SOAP/W3C: SOAP is a more complex XML-based messaging protocol; W3C is the World Wide Web Consortium, the main web standards body. The author presents SOAP+W3C as the corporate/standards “capture” of a simpler idea. - Uncertainties/contested points: - The evaluation that the W3C process “didn’t yield anything useful” is a strong, opinionated claim; many enterprise systems did use SOAP. The article is explicit about being a personal recollection, and the author notes his memory was imperfect and hurried for the podcast. - Attribution of credit between the author and Microsoft engineers is acknowledged as ethically gray; he notes feeling conflicted about publishing XML-RPC without their names. --- ### 🗒️ Notes - The piece begins with meta-commentary: the show notes were drafted by Claude.ai and may contain mistakes; listeners must hear the podcast for the exact views. The author notes the AI wrote in first person, which he would have preferred to be third person, and appends his own corrections. - Motivation and historical context: - In 1998, the author’s company had built Frontier, “a comprehensive scripting environment with object database, editor, debugger, and extensive verb set” that provided “one unified way to do things instead of JavaScript's fifty million ways,” and had strong networking and desktop publishing integration. - Apple, whose platform Frontier originally targeted, “felt threatened” and put up political/organizational roadblocks. The author describes Apple as having “a lot of bad stuff happening,” and his project as one of the casualties, forcing a move from Mac to Windows. - Problem definition: - The core technical problem: reliable communication between Mac and Windows systems with incompatible networking stacks. - Insight: Use ubiquitous web infrastructure as the bridge—HTTP transport plus XML as a neutral, parseable encoding—leading to the realization encapsulated as “HTTP plus XML equals RPC.” - Microsoft engagement: - After the author blogged the idea, Bob Atkinson from Microsoft called; Bill Gates was a regular reader of the author’s blog and would forward posts internally with “What do you think?” queries, keeping Microsoft leadership informed of the author’s work. - A meeting at Microsoft Redmond was arranged with Bob and another experienced programmer. These were highly valued engineers who wanted to stay on the technical track rather than move into management. - The author emphasizes a “spoiler”: it is easier for an independent developer to push through a new protocol than for senior engineers within a large company, even if they are well-compensated and have big titles. Organizational friction blocks simple, cross-cutting innovations. - He draws a parallel to Apple, where a senior executive wanted a scripting environment but could not get Apple engineers to build it; once they heard of the external initiative, they obstructed it. Takeaway: incumbent developers can “hold back progress” when threatened. - Design debate: functions vs objects: - Don Box, another independent developer, joins the one- or two-day design session at Microsoft. - They brainstorm and sketch; Microsoft sends an example. The author scrutinizes “every detail” and pushes back over calls. - Philosophical divide: - Author: favors RPC semantics—simple function calls—because every programmer understands function calls and “everything is a function call if you go deep enough to machine language.” - Microsoft engineers: want objects, classes, and built-in extensibility, reflecting an enterprise, object-oriented worldview. - The author accepts the push for objects (“let’s go for it”) but immediately documents the resulting spec and shares it with the other three participants. He receives no replies, “complete silence,” despite follow-ups. - Publication and aftermath: - Feeling conflicted about shared intellectual contribution, the author publishes XML-RPC under his name alone, while acknowledging internally that it was not entirely his creation. - His team builds the reference implementation in Frontier, hosts a public test server, and actively evangelizes via his popular blog, driving adoption. - Within Microsoft, similar work evolves into SOAP, which then becomes the basis for a W3C standardization effort. At the first W3C SOAP meeting, about 100 people attend—full-time standards staff and major vendors ensuring representation. - Critique of standards process: - The author claims XML-RPC, as originally defined and implemented, “yielded something useful,” while the W3C SOAP process did not, because: - Large, complex organizations needed to support many legacy systems and internal agendas. - This drove the spec toward maximal accommodation and complexity, away from a minimal solution. - The dynamic exemplifies “bringing what was wrong with the tech industry to the web.” - He argues that a better path would have been: - Ship simple XML-RPC. - Build real applications first. - Convene a developer-only meeting a year later to decide next steps informed by practical experience, not preemptive requirements from large vendors. - Reflection and present-day warning: - The author notes he made “one big mistake” in his earlier telling but corrected it quickly: he misnamed the original blog post; the correct phrase was “RPC over HTTP via XML.” - He states he understood Microsoft’s internal SOAP process “very soon after XML-RPC was released” and explains it as an attempt to recreate the existing networking world and bridge competing approaches. - He laments that XML-RPC was “a seed” whose potential Microsoft “fully understood” but never built on. - Drawing a parallel between 1998 and 2026, he suggests we are again at a moment where the web’s potential could be reshaped. As with podcasting, the web can win when: - We “follow the grain of the web” instead of corporate strategies. - We “work for all developers, not just ones at big corporations.” - We empower users; otherwise, “you don't do it.” - The explicit warning: when you ask “what can go wrong?” absence of imagination is not evidence of safety; unanticipated problems can still exist. - Meta note: the author says he sounds “really tense” in the podcast, rushed for time and relying on imperfect memory rather than thorough research in his 1998 blog posts. --- ## 📚 References - “How XML-RPC started up” (original article): https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html - Historical XML-RPC spec and docs (background, not cited but relevant): http://xmlrpc.com/spec - W3C SOAP (context for later standardization): https://www.w3.org/TR/soap/ --- ## 🗣️ Paraphrase - Paragraph A paraphrase: In the late 1990s, facing broken interoperability between Mac and Windows, the author leveraged HTTP and XML to design XML-RPC—a minimal, function-call style protocol exposed over the web. Early collaboration with Microsoft engineers stalled, so he independently published the spec, shipped a reference implementation, and evangelized it via his blog. - Paragraph B paraphrase: Over time, Microsoft reworked the ideas into SOAP and took them to W3C, where complexity and corporate agendas diluted the original simplicity. The author argues that XML-RPC’s lean, working design delivered more practical value than the heavy standards process and warns that today’s web and AI inflection point should prioritize simple, open, developer-centric infrastructure over corporate strategy. --- ## 📰 Newsletter In today’s history-nerd corner, we’re rewinding to 1998 and the birth of XML-RPC—the humble, HTTP-over-XML workhorse that quietly paved the way for a lot of early remote publishing (including WordPress’s own XML-RPC endpoint). This origin story is a useful mirror for 2026: a simple, developer-driven protocol gets pulled into corporate and standards gravity wells, grows more complex, and loses its original elegance. Sound familiar? For WordPress folks, a few takeaways: - Simple, boring HTTP APIs age better than heavyweight abstractions. - Independent developers can (and do) seed the infrastructure large platforms rely on. - The web works best when we build real apps first, then standardize from experience—not the other way around. If you’re interested in how this connects to modern WordPress APIs: - Revisit the [REST API Handbook](https://developer.wordpress.org/rest-api/). - Compare it with legacy [XML-RPC support](https://developer.wordpress.org/xml-rpc/) and how clients still rely on it. - Think about what today’s “XML-RPC moment” might be for AI + WordPress: lightweight, open primitives that anyone can build on, before big vendors freeze the stack. --- ## ✅ Action Items #### DevRel - Developer advocacy: - Prepare a talk: “From XML-RPC to WP REST API: Lessons from Simple Protocols” for WordCamps and meetups. - Create a short demo showing a client talking to WordPress via both XML-RPC and REST, highlighting tradeoffs. - Education: - Design a workshop on “Designing Small, Stable Web APIs” using XML-RPC history as a case study. - Add a curriculum module on “standards vs. shipping” to internal onboarding for developer advocates. - Developer experience: - Produce code samples that show how to call WordPress APIs with as few abstractions as possible (plain HTTP examples). - Audit SDKs and quickstarts for unnecessary complexity that echoes SOAP-style over-engineering. - Developer marketing: - Run a content series: “Under the Hood: The Simple Protocols Powering WordPress,” referencing XML-RPC as a historical anchor. - Track engagement with posts that emphasize simplicity and longevity of APIs. - Community management: - Host a discussion thread on “What should remain simple in the WordPress stack?” and collect feedback. - Use insights to influence contributor priorities around REST API and future AI integrations. - Internal/external/cross-project: - Align with browser, hosting, and client-app partners on keeping integration points simple and HTTP-first. - Set up a feedback loop from plugin and app developers on API friction points. #### OSPO - Policy & Governance: - Draft guidance that favors small, composable protocols over large, monolithic frameworks for new open standards. - Clarify decision rights for when the org participates in heavy standards bodies versus shipping de facto protocols. - License Compliance: - Ensure any XML-RPC-related or legacy interop libraries used in-house are properly tracked and compliant. - Schedule periodic scans for RPC/interop dependencies in critical paths. - Security Management: - Review historical XML-RPC and SOAP-era vulnerabilities as cautionary examples in security training. - Define clear policies for exposing remote procedure endpoints (rate limits, auth, logging). - Software Inventory: - Maintain an inventory of all RPC-like endpoints (XML-RPC, REST, GraphQL) across products. - Set freshness SLOs for documentation and SBOMs related to these endpoints. - Developer Support: - Offer consultation hours for teams designing new APIs, pushing them toward simple, HTTP-native interfaces. - Provide patterns and threat models that avoid SOAP-style complexity. - Community Engagement: - Support upstream projects that keep core web plumbing simple and interoperable. - Consider MOUs with key open-source projects building HTTP-first protocols. - Strategic Alignment: - Include “simplicity of integration” as a top-level KPI for platform initiatives. - Report to leadership on how standards participation affects time-to-ship and developer happiness. #### Community - Maintainers: - Run roadmap clinics to identify and de-scope overly complex API designs. - Encourage maintainers to document “minimal viable interoperability” first. - Contributors: - Create “first issue” labels around improving docs for core APIs and simplifying examples. - Pair new contributors with maintainers for small “replace complexity with clarity” refactors. - Sponsors: - Tie sponsorship milestones to improved developer ergonomics and simpler integration paths. - Publish impact reports showing how simplicity correlates with adoption. - Ecosystem: - Coordinate incident drills around API breakage or deprecation, emphasizing stable, minimal contracts. - Practice shared disclosure practices for vulnerabilities in common protocols. #### WordPress - Core: - Prioritize keeping core APIs small, predictable, and well-documented. - Use XML-RPC’s history as a cautionary tale in discussions about new abstraction layers. - Core Performance: - Profile the overhead of protocol layers and serialization formats (XML vs JSON). - Set performance budgets that discourage over-complex middleware. - Core AI: - Define guidelines for AI-related endpoints that favor transparent HTTP+JSON interfaces over opaque services. - Curate evaluation sets that test latency and reliability of new protocol designs. - **Core Program Team:** - Schedule cross-team retros that ask, “Are we accidentally reinventing SOAP?” - Track dependencies between new features and underlying protocol complexity. - Mobile: - Keep mobile app API dependencies limited to stable, minimal endpoints. - Provide offline-friendly sync patterns that don’t require heavy protocol stacks. - Playground: - Offer labs where developers can inspect and replay raw HTTP traffic to WordPress APIs. - Create exercises that show the differences between XML-RPC and REST calls. - Community: - Include a “History of WordPress Interop” talk template in meetup kits. - Encourage discussions on “what we should NOT standardize yet.” - Training: - Build lesson plans on “Simplicity in Web APIs” with XML-RPC as a core case study. - Consider a certification module that evaluates understanding of protocol tradeoffs. - Marketing: - Highlight WordPress’s long commitment to open, simple HTTP APIs. - Tell stories of independent devs who built successful tools on top of WordPress APIs. - Support: - Maintain clear troubleshooting paths for legacy XML-RPC clients vs REST clients. - Document when to use which endpoint and how to migrate. - Design: - Ensure developer tools surface raw requests/responses clearly, not just SDK layers. - Use UX patterns that emphasize the “mental model” of simple requests and responses. - Documentation: - Fill DevHub/HelpHub gaps around protocol history, migration, and best practices. - Favor examples-first patterns that start from plain curl or fetch calls. - Photos: - Curate visuals that show the “layers” of WordPress architecture, including APIs. - Maintain taxonomy that clearly tags protocol- and API-related assets. - TV: - Produce short explainer videos on “How WordPress Talks to the World.” - Ensure captions are accurate for technical terminology. - Polyglots: - Localize API docs and tutorials so non-English-speaking developers can adopt them easily. - Align glossaries around core protocol terminology. - Accessibility: - Ensure API docs are accessible and navigable for assistive technologies. - Provide high-contrast code examples and diagrams. - Meta: - Stabilize .org APIs used by the plugin and theme directories. - Monitor API reliability dashboards and error budgets. - CLI: - Keep WP-CLI commands thin wrappers around HTTP APIs where possible. - Provide scaffolds that encourage simple service designs. - Hosting: - Create host-level checklists that validate API connectivity (XML-RPC, REST). - Encourage sane defaults (no unnecessary blocks on core APIs). - Tide: - Incorporate checks related to misuse or overcomplication of external APIs in plugins. - Provide feedback loops to reduce false positives. - Openverse: - Keep ingestion APIs publicly documented and as simple as possible. - Offer examples for self-hosted and third-party integrations. - Themes: - Encourage theme devs to use lightweight API calls only where necessary. - Provide test matrices that cover key API interactions. - Plugins: - Guide plugin authors toward stable, minimal integration protocols. - Include security liaisons for plugins that expose remote-call surfaces. #### The WPOCC - Programs: - Fund fellowships focused on web protocol literacy and simple API design. - Offer microgrants for tools that demystify HTTP-level interactions. - Projects: - Run governance clinics on “When to Standardize vs. When to Ship.” - Sponsor documentation sprints capturing “lessons from XML-RPC and SOAP.” - Funding experiments: - Pilot matched grants for projects building open, simple AI and data APIs on WordPress. - Publish transparent ledgers showing the impact of protocol-simplifying work. ### FAIR - Technical independence: - Prefer protocols that can be self-hosted and inspected (no opaque dependencies). - Encourage signature checks and provenance for critical API payloads. - Policies and covenants: - Require transparency around vendor influence on any standards WordPress adopts. - Use sunset clauses for experimental APIs that skew too complex. - Productized governance artifacts: - Produce lightweight charters for protocol workgroups. - Maintain scorecards that track simplicity, openness, and adoption. --- ## 🧪 Hypotheses - H1: Simple, function-call style web protocols (like XML-RPC) lead to faster and broader grassroots adoption than complex, object-heavy standards (like SOAP). - H2: Independent developers are more likely than large-company engineers to successfully ship new cross-platform web protocols. - H3: Standards processes dominated by large vendors systematically increase protocol complexity without proportional practical benefit. - H4: Building real applications before standardizing produces better, more durable protocols than designing by committee upfront. - H5: In 2026, web/AI infrastructure that “follows the grain of the web” will see higher long-term usage than corporate-strategy-driven stacks. --- ### 📊 Methodology - Study designs: - Comparative adoption study: Collect historical data on adoption curves of XML-RPC vs SOAP (and later REST) across open-source projects and commercial products. - Organizational case studies: Interview independent developers and big-company engineers who participated in protocol efforts, focusing on decision-making and blockers. - Standards impact analysis: Review W3C archives, mailing lists, and specs to quantify length, feature creep, and complexity growth over time. - Data sources: - Open-source repos (GitHub, SourceForge archives) for protocol usage. - Mailing list archives and meeting notes from XML-RPC, SOAP, and W3C groups. - Product documentation from major platforms that adopted (or rejected) each protocol. - Analyses: - Time-series analysis of adoption vs protocol complexity. - Qualitative coding of interviews around themes: simplicity, politics, shipping pressure. - Comparative evaluation of protocol ergonomics (number of concepts, lines-of-code for “hello world” integration, etc.). --- ### ❓ Questions - How much did SOAP’s complexity actually hinder adoption compared to business and tooling factors? - What governance models best protect simple web protocols from corporate capture? - How can today’s AI and web API designers bake in “simplicity constraints” from the start? - What metrics should standards bodies adopt to guard against over-specification? - How can WordPress and similar ecosystems institutionalize a bias toward small, composable interfaces? --- ### 🔮 Future Research - Systematic histories of web protocols that “stayed small” vs those that ballooned under standardization. - Comparative research on independent protocol innovations vs corporate ones across multiple eras (CGI, RSS, XML-RPC, REST, GraphQL, etc.). - Sociotechnical studies of how blog posts and informal writing (like the author’s) influenced big vendors’ decisions. - Design patterns for “minimum viable interoperability” in emerging AI and data standards. --- ### 💡 Implications - Practice: API designers should default to minimal, understandable HTTP interfaces and resist unnecessary abstraction layers. - Policy: Standards bodies and foundations need guardrails that prioritize implementer experience and real-world deployments over theoretical completeness. - Security: Simpler protocols are often easier to audit and secure; complexity can hide misconfigurations and vulnerabilities. - Education: Curricula should include historical case studies (like XML-RPC vs SOAP) to teach protocol design tradeoffs. - Funding models: Grants and sponsorships can explicitly reward projects that maintain simplicity and openness over time. --- ### 🧠 Learning Styles Assessment - Reading level estimate: - Roughly late high-school to early college level (Flesch–Kincaid style estimate: ~11–12), due to technical terms and historical context. #### 👀 Visual learners - Present: - Mainly text-based narrative; no diagrams or charts. - Improve: - Architecture diagrams showing XML-RPC vs SOAP vs REST. - Timelines of key events from 1998 to the W3C meetings. - Before/after visuals comparing “simple” vs “complex” protocol stacks. #### 🔊 Aural learners - Present: - The article is tied to a podcast episode; the audio is central. - Improve: - A concise 2–5 minute audio recap focused just on the protocol lessons. - Optional TTS version of the written notes. - Speaker notes summarizing each core idea. #### 🗣️ Verbal learners - Present: - Rich narrative, definitions of concepts like RPC, and concrete examples. - Improve: - More explicit glossaries of terms (RPC, SOAP, W3C, Frontier). - Clear analogies (e.g., function calls as “remote buttons”). #### 🧩 Kinesthetic learners - Present: - No interactive components. - Improve: - Hands-on labs: send XML-RPC and REST calls to a sample server. - Step-by-step exercises to implement a trivial XML-RPC endpoint. #### 🧠 Logical learners - Present: - Causal reasoning about how organizational structure affects protocol outcomes. - Implicit timelines and comparisons. - Improve: - Explicit tables comparing XML-RPC, SOAP, and REST on complexity metrics. - Decision trees for “when to standardize vs just ship.” #### 🧑‍🤝‍🧑 Social learners - Present: - Story of collaboration and conflict among individuals and organizations. - Improve: - Discussion prompts for groups (“What would you have done at Microsoft?”). - Moderated Q&A sessions or forums reflecting on lessons learned. #### 🧘‍♀️ Solitary learners - Present: - Self-contained narrative suitable for reflective reading. - Improve: - Reflection questions at the end (“How does this affect your API design?”). - Short self-check quizzes about protocol tradeoffs. #### 🌿 Naturalistic learners - Present: - No explicit environmental or sustainability framing. - Improve: - Analogies between protocol ecosystems and natural ecosystems (biodiversity vs monoculture). - Discussion of resource usage implications of heavy vs light protocols. --- ### 📊 Accessibility Assessment #### Screen reader semantics - Present: - Simple HTML page likely with basic headings and text; audio element for the podcast. - Improve: - Ensure correct heading hierarchy and descriptive alt text for any non-text media. - Provide clear labels on the audio player. #### Keyboard navigation - Present: - Likely standard browser controls; minimal interactivity. - Improve: - Confirm tab order is logical and that the audio player is fully keyboard-accessible. - Provide visible focus indicators. #### Contrast and readability - Present: - Depends on site styling; scripting.com tends to be fairly minimal. - Improve: - Verify 4.5:1 contrast for text and links. - Ensure adequate line spacing and font size. #### Text resizing and reflow - Present: - Likely responsive, but unverified. - Improve: - Test at 200% zoom for clipping or horizontal scrolling. - Respect user “prefers-reduced-motion” settings. #### Media and captions - Present: - Embedded audio element. - Improve: - Provide a full, accurate transcript for the podcast. - Avoid autoplay and offer downloadable audio/transcript. #### Forms and interactions - Present: - Minimal or none on the page. - Improve: - If any forms exist (comments, etc.), ensure proper labels and error messages. #### Standards reference - Map gaps to WCAG 2.2 AA: - Captions/transcripts (1.2.x). - Contrast (1.4.3 / 1.4.11). - Keyboard access (2.1.x). - Focus visible (2.4.7). --- ### 🌍 DEIB Assessment #### Cultural breadth - Present: - US/Western tech-industry centric narrative (Apple, Microsoft, W3C). - Improve: - Reference web protocol work from other regions or communities. - Offer multi-language versions where possible. #### Inclusive language - Present: - Generally neutral, direct language. - Improve: - Reduce insider jargon or briefly define it. - Avoid metaphors that assume specific cultural backgrounds. #### Neurodiversity support - Present: - Linear narrative; some chunking by paragraphs. - Improve: - More headings and subheadings to break up text. - Consistent patterns and summaries after dense sections. #### Representation - Present: - Focuses on a small set of (mostly unnamed) male industry figures. - Improve: - Highlight contributions from more diverse protocol designers where relevant. - Use inclusive examples and imagery in any companion material. #### Psychological safety - Present: - Critical but not hostile tone toward organizations. - Improve: - Explicitly invite differing perspectives on standards and protocol history. - Provide links to codes of conduct for any related discussion spaces. --- ### ✅ Logical Validity #### Strong reasoning - Type: Causal and inductive. - The author argues that organizational complexity in big companies and standards bodies leads to protocol complexity and reduced usefulness. This is supported by concrete examples (Apple scripting environment, Microsoft SOAP/W3C). - The reasoning is strong where he connects incentives (need to represent all internal interests) to outcomes (complex specs) and then to consequences (harder adoption). - Clarification: - Could be strengthened with explicit contrasting cases where simple, independent standards succeeded (e.g., RSS, early RESTful APIs) and with more data than anecdote. #### Fallacies - Potential hasty generalization: - From the SOAP/W3C experience, the author suggests that standards processes broadly “don’t yield anything useful.” There are counterexamples (HTTP, HTML, CSS). - Fix: Narrow the claim to “in this specific case” or “in cases dominated by large vendors with many legacy constraints.” - Possible survivorship bias: - Focuses on successful independent efforts without acknowledging failed simple protocols. - Fix: Note that independence is helpful but not sufficient; many independent ideas don’t take off. #### Tone of voice - Tone: - Reflective, mildly combative toward large organizations, pragmatic about shipping software. - Uses plain, conversational phrasing (“fifty million ways,” “what can go wrong?”) and occasional humor/irony. - Admits fallibility (tense delivery, imperfect memory, misnaming). --- ### 🛡️ DARVO Analysis - Deny: - The article does not primarily use denial; instead, it acknowledges tensions and mistakes (e.g., misnaming the original blog post, conflict about attribution). - Attack: - There is criticism of Apple engineers and large-company developers for “holding back progress,” but it is aimed at systemic behavior rather than personal attacks. - Reverse victim/offender: - The author does not present himself as a victim in a manipulative way; he relates setbacks (Apple resistance, Microsoft silence) but frames them as structural examples, not as grounds for moral reversal. - Overall: - The narrative is opinionated but not DARVO-like; it critiques institutions and processes more than individuals and accepts some shared responsibility. --- ## 🎯 Conclusion - Bottom line: XML-RPC’s origin story illustrates how simple, independently-driven web protocols can unlock powerful cross-platform integration but are vulnerable to being overshadowed by complex, corporate-led standards like SOAP. The author urges today’s builders—especially in a 2026 landscape that feels like 1998 again—to favor small, web-native, developer- and user-centric infrastructure, build real apps first, and only then standardize from lived experience. - Next steps for readers: - Reflect on where you might be over-engineering protocols in your own work. - Study historical cases (XML-RPC, SOAP, REST, WordPress APIs) before adopting new standards. - Advocate within your projects and organizations for simplicity, openness, and real-world testing before committee-driven complexity. --- ## 🧱 Refactor Appendix (append after 🎯 Conclusion) ### 📚 Literature Split Pad - Purpose: Stage Konik CEE units that become per-source Literature notes. - Split level: **H3**. - Include verbatim quotes under 25 words and a [view highlight] link. ### [H1] 5–10-word present-tense claim > [!quote] [How XML-RPC started up](https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html) by [[scripting.com]] via [[scripting.com]]. Published 2026-01-17. > “HTTP plus XML equals RPC.” Two lines: context and use. Cite data if relevant. [view highlight](https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html#H1) #xref #articleseed ID:rw_[MISSING] ### [H2] 5–10-word present-tense claim > [!quote] [How XML-RPC started up](https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html) > “Within large companies, ideas cannot stay simple.” Two lines: context and use. [view highlight](https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html#H2) #xref ID:rw_[MISSING] --- ### 🔖 Atomic Split Pad (Zettel Candidates) - Purpose: Promote reusable claims into Atomic notes. - Split level: **H4**. - Each item: one idea, present tense, specific, testable. #### [Z1] Simple web protocols outcompete complex standards - Applies when independent developers can ship and iterate quickly on HTTP-based designs. - Pointer: How XML-RPC started up — XML-RPC vs SOAP discussion. - Links: [[Web-Protocols]] [[Standards-Dynamics]] #### [Z2] Big-company standards processes increase protocol complexity - Holds when many vendors and legacy systems must be accommodated in a single spec. - Pointer: W3C SOAP meeting anecdote in the article. - Links: [[Standards-Governance]] [[Organizational-Complexity]] --- ### ✏️ Fleeting Queue (Extract by Selection) - Purpose: Capture quick actions or sparks for Fleeting notes. - Extraction: **Select one line** → “Refactor: Extract selection to new note (content only).” - Keep each line short and self-contained. - [F1] Map XML-RPC vs SOAP vs REST as a teaching diagram — context/https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html #fleeting #inbox - [F2] Draft a WordCamp talk on “Simple protocols and WordPress APIs” — context/https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html #fleeting #inbox - [F3] Research other independent protocol successes (RSS, etc.) — context/https://shownotes.scripting.com/scripting/2026/01/17/howXmlrpcStartedUp.html #fleeting #inbox ---