Download the PHP package wp-php-toolkit/bytestream without Composer
On this page you can find all versions of the php package wp-php-toolkit/bytestream. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download wp-php-toolkit/bytestream
More information about wp-php-toolkit/bytestream
Files in wp-php-toolkit/bytestream
Package bytestream
Short Description ByteStream component for WordPress.
License GPL-2.0-or-later
Homepage https://wordpress.github.io/php-toolkit/reference/bytestream.html
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package bytestream
slug: bytestream title: ByteStream install: wp-php-toolkit/bytestream
see_also:
- filesystem | Filesystem | Back file reads and writes with the same stream primitives.
- zip | Zip | Read and write archive entries one stream at a time.
-
httpclient | HttpClient | Process request and response bodies incrementally.
Composable streaming primitives for reading, writing, transforming, hashing, and compressing byte data. Pull/peek/consume semantics let parsers backtrack without copying, and deflate, inflate, and checksum filters snap together like Lego.
Why this exists
PHP's native streams are powerful but inconsistent. fread on a socket may return short reads with no warning; stream_filter_append is awkward to compose; gzip helpers and file handles expose different APIs. The ByteStream component normalizes these behind one small interface — pull / peek / consume — so a parser, a hash function, and a deflate filter all see the same shape.
The split between pull (buffer up to N bytes) and consume (advance past N bytes) is the secret. Parsers can peek ahead to detect a record boundary and decide whether to consume, without copying or allocating.
Read a file in chunks
The canonical loop. pull(N) reads up to N bytes from the underlying source into an internal buffer and returns how many ended up there; consume(N) reads N bytes from that buffer and advances past them. The buffer never grows beyond the chunk size you ask for.
MemoryPipe as write-then-read buffer
MemoryPipe is bidirectional: you append_bytes() as a writer and pull/consume as a reader. Easiest way to wire one component's output into another's input.
Gotcha: A producer must call close_writing() when done — otherwise the consumer eventually throws NotEnoughDataException instead of seeing EOF.
Compress on the way in, decompress on the way out
Wrap a stream in DeflateReadStream to get compressed bytes out; wrap it in InflateReadStream to get decompressed bytes out. Both are full ByteReadStream implementations, so they nest into anything else that takes a stream.
Line-by-line reads from a chunked source
Reading text by line means handling chunk boundaries that fall mid-line. Keep the trailing partial line and prepend it to the next pull. The rest of the loop pretends the data was always whole.
Limit a stream to a fixed window
LimitedByteReadStream exposes only the next N bytes of an underlying stream as if those were the entire stream. This is how the ZIP decoder hands you the body of one entry without letting you read into the next.
