Net Socket Laravel Package

Product Decisions This Supports

• Transport-layer plumbing for outbound mail/notifications. If any roadmap item depends on SMTP delivery through a legacy PEAR stack (Net_SMTP), Net_Socket is the underlying TCP/SSL transport. It is an enabler, not a user-facing feature — decide on it as infrastructure, not as a product bet.
• Legacy protocol integrations. Custom line-based TCP clients, POP3/IMAP mailbox polling, or connections to older internal services that don't speak HTTP. Relevant when scoping "integrate with system X" work and estimating whether a rewrite is required.
• Build vs. buy vs. reuse. This is a reuse answer: a thin object wrapper over PHP sockets. The real decision is "keep the existing transport or replace it," and this package is the baseline for that comparison.
• Technical-debt and upgrade planning. Last release 2017 places it in the dependency inventory that gates PHP 8.x readiness, deprecation cleanup, and security review. Feeds a keep/fork/replace decision in the next planning cycle.
• Supply-chain risk posture. The upstream repository is unverified and the package has 17 GitHub stars — effectively no community scrutiny. That informs whether we vendor/pin it, fork it, or forbid new usage via policy.
• Licensing sign-off. BSD-2-Clause is permissive and commercially safe; no legal blocker for redistribution in a closed product.

When to Consider This Package

Consider it when:

• You are maintaining or extending an existing PEAR-based stack (Net_SMTP, Net_POP3, Net_IMAP, HTTP_Request) and a rewrite is out of scope this quarter.
• You need a minimal, synchronous, blocking socket client for a simple protocol and want to avoid a larger dependency tree.
• It is already pulled in transitively and removing it costs more than pinning it.
• Your legal/compliance team needs a permissive license with no attribution overhead beyond notice retention.

Look elsewhere when:

• The work is greenfield Laravel. Use Laravel's HTTP client (Guzzle) for HTTP, Symfony Mailer for email, and native stream_socket_client or ReactPHP/AMPHP for raw sockets.
• You need async/non-blocking I/O, connection pooling, retry/backoff, structured TLS configuration, or observability hooks (logging, tracing, metrics).
• You require active maintenance, documented PHP 8.4+ support, or a security response commitment — the 2017 release date and near-zero community footprint are disqualifying for a new dependency.
• You need PSR-4/PSR-7/PSR-18 interoperability, Composer-native autoloading, or exception-based error handling; this is pre-PSR, PEAR-style naming with error codes.
• You cannot verify provenance — the repository is unknown, so source audit and vendoring are prerequisites, not optional.

How to Pitch It (Stakeholders)

For executives: This is not a new platform investment or a strategic bet. It is a small, permissively licensed (BSD-2-Clause) transport utility that only matters if we keep legacy PEAR mail or socket code alive. The cost to keep is near zero; the cost of the tail is the concern — it last shipped in 2017, has an unverified upstream, and effectively no community. Recommendation: do not standardize on it. Size a small replacement workstream for every code path that depends on it and fund that as debt retirement, not as new capability.

For engineering: Treat it as a compatibility shim, never a foundation. Its value is a stable blocking socket API and PEAR ecosystem fit; its weaknesses are age, no PSR support, no Composer-native ergonomics, and thin maintenance. If we touch it: pin the exact version, vendor or mirror the source, wrap it behind our own transport interface so the dependency is swappable, enforce explicit connect/read timeouts, and record an ADR naming the migration target (Guzzle / Symfony Mailer / ReactPHP). New code should not import it directly.

One-line ask: Approve continued use behind a wrapper for existing paths only, with a dated migration target and a policy bar on new adopters.