Laminas Xmlrpc Laravel Package

Product Decisions This Supports

• Integration roadmap / must-have feature delivery: Any feature that requires talking to an existing XML-RPC endpoint — legacy ERP/CRM (e.g. Odoo-style APIs), publishing platforms (MetaWeblog-style blog posting), ticketing/wiki systems, or a partner's on-prem system — can ship without building a serializer, parser, and fault mapper from scratch.
• Build vs. buy: The value here is correctness of a well-specified wire format (typed value objects for structs, arrays, dates, base64, booleans) plus spec-compliant fault mapping. Writing this in-house is days of work plus permanent edge-case risk; adopting a small, permissively licensed dependency behind an adapter is the cheaper and lower-risk call.
• Exposing our own API surface: The server component (request→callable mapping, system.listMethods introspection, caching of introspection results) supports decisions like "offer an XML-RPC endpoint to a specific enterprise customer/partner who cannot consume our REST API."
• Architecture / boundary decisions: Because 3.x removed the bundled Laminas HTTP dependency, adopting this forces an explicit decision on which HTTP client we standardize (our existing PSR-18/Guzzle stack), which is a healthy push toward consistency rather than a new transport silo.
• Prioritization and deprioritization: This package does not justify adding XML-RPC to the platform roadmap. If no current counterparty mandates XML-RPC, the correct product decision is to skip it — REST/JSON remains the default for anything we control on both ends.
• Migration strategy: Useful as a short-lived bridge while a partner migrates off an XML-RPC contract; scoped as an adapter, it can be retired cleanly.

When to Consider This Package

Adopt when:

• You have a named, unavoidable XML-RPC counterparty — a vendor, customer, or legacy system whose endpoint you cannot change and which has no REST/JSON alternative.
• You are on PHP 8.1+ and comfortable adding a Laminas-namespaced dependency to a Laravel app; the library is framework-agnostic, so it lives behind your own service class rather than leaking into controllers.
• You need both directions — consuming a remote service and standing up an endpoint for a partner — since one small dependency covers the client, server, and typed value objects.
• You want standards compliance cheaply: fault codes/exceptions, introspection (system.listMethods), and correct encoding of dates/base64 are exactly the parts teams get wrong when hand-rolling.
• License and maintenance posture matter: BSD-3-Clause, a documented release history, and a maintained project (PHP 8.4 coverage, Psalm/type-coverage badges) clear typical procurement/procurement-lite review.

Look elsewhere when:

• The counterparty offers REST, JSON, or gRPC — use that; XML-RPC is a legacy protocol and no new internal API should be designed around it.
• You need ecosystem depth: 25 stars and zero dependents means no Laravel wrapper, no community recipes, and effectively no third-party answers to problems. Budget for reading the source (it is small) and owning the integration yourself.
• You need commercial SLAs, long-term support guarantees, or multiple maintainers. This is a volunteer-maintained Laminas package in a niche area; assume you may need to pin a version or vendor/fork.
• Your security review forbids XML parsing of untrusted input without strict controls. XML-RPC is a classic XXE and entity-expansion surface; only adopt if you can enforce safe libxml flags (the library exposes LIBXML_ flags — set them, don't default), disable entity loading, and restrict egress/ingress.
• You require non-HTTP transports or streaming semantics — out of scope for this implementation.
• You are on an older PHP/Laravel version pinned below the library's supported range (2.10+ requires PHP 7.2; 3.x assumes modern PHP), which would force a stale branch.

How to Pitch It (Stakeholders)

For executives (one paragraph):

Partner/legacy integration X requires the XML-RPC protocol — the other side cannot offer a modern API. Rather than build and permanently maintain a protocol implementation, we adopt laminas/laminas-xmlrpc, a small BSD-3-licensed component from the Laminas project with a documented release history and current PHP support. It is a narrow, single-purpose dependency: it does not touch our product architecture or customer-facing APIs. We will confine it to one integration module behind an internal interface, so if the partner modernizes or the protocol is retired, we remove one adapter rather than unwinding a platform commitment. Cost: one dependency plus a few days of integration work; risk: low adoption means we largely support ourselves, which is acceptable given the codebase size and that it is not on our critical path beyond this one integration.

For engineering leads (what they actually get and what they must own):

• Framework-agnostic client and server: request serialization, response parsing, typed value objects, and fault exceptions that we map into our domain error model.
• Note the 3.0 breaking change: Laminas HTTP was removed, so we supply the transport — wire the client to our existing PSR-18/Guzzle stack via the container; no new HTTP stack, one less thing to secure and observe.
• Wrap it: one XmlRpcGateway interface with a thin implementation, contract tests against the partner's sandbox, and timeouts/retries/telemetry at our adapter layer. Nothing outside the integration module imports a Laminas class.
• Harden the parser: pass explicit LIBXML_ flags, disallow external entities, cap response size, and treat all remote values as untrusted input validated against our own DTOs.
• Maintainability: pin the minor version, subscribe to releases (frequent, small, semver-tagged), and keep the adapter ~200 lines so a fork is a realistic fallback if upstream stalls.