ISSUE-7: S3ObjectSeeker

[DiegoPino]

@digitaldogsbody this works but lacks still
1.- Update on composer.json to require the aws-sdk which we need (as sanity)
2.- Tests
3.- Add the fetch file method

How I tested this (so far)?

• Using minio with a test bucket and credentials minio/minio123 running localhost.
• Uploaded a 400Mb ZIP

Created a test Project with this composer.json (in this case this will go for PHP 8.1 which is actually good)

{
"name": "test/test",
"repositories": [{
    "type": "vcs",
    "url": "http://github.com/DiegoPino/mingulay"
}],
    "require": {
        "digitaldogsbody/mingulay": "dev-ISSUE-7",
        "aws/aws-sdk-php": "^3.235"
    }
}

and with file at /src/test.php

<?PHP
require '../vendor/autoload.php';

use Aws\S3\S3Client;
use Aws\Exception\AwsException;

$credentials = new Aws\Credentials\Credentials('minio', 'minio123');

$s3 = new Aws\S3\S3Client([
    'version' => 'latest',
    'region' => 'us-east-1',
    'endpoint' => 'http://localhost:9000',
    'use_path_style_endpoint' => true,
    'credentials' => $credentials
]);
$s3->registerStreamWrapper();

$seeker2 = new \Mingulay\Seeker\S3ObjectSeeker("s3://test/NYHS.zip");
$zip_info2 = new \Mingulay\ZipRangeReader($seeker2);
var_dump($zip_info2->files);

[DiegoPino]

@digitaldogsbody will test now if copy stream is a good/performance option. I guess we could also pass directly back an open stream and let caller do the copy/consume/anything? Or we could have extra $mode argument in the signature to allow either the file to be passed back, the fully copied stream or the original open stream to be consumed.

[digitaldogsbody]

Looks great so far :)

[digitaldogsbody]

@digitaldogsbody will test now if copy stream is a good/performance option. I guess we could also pass directly back an open stream and let caller do the copy/consume/anything? Or we could have extra $mode argument in the signature to allow either the file to be passed back, the fully copied stream or the original open stream to be consumed.

I think the problem with passing back the open stream is that for some Seekers the caller will then need to know the offset and length to retrieve (which is of course, technically possible from $files (with an extra method to expose the offset of the compressed data rather than the Local File Header record)).

For S3Seeker it would be fine, as you are limiting the read bytes with the stream wrapper, but for LocalFileSeeker, the stream would just be to the whole zip file (hence the current use of a php://temp stream instead), and so it would lead to inconsistent behaviour from the library depending on which seeker you initialised it with.

This is why I was thinking about the PartialReader utility class, because with that we could make the same behaviour in LocalFileSeeker as you would get from S3Seeker, and just be able to simplify ::getStream down to returning a file pointer. I'd need to do some experiments to work out where to put the decompression filter in this pattern, but I am sure it will work.

The extra mode is a good idea, but maybe to keep the interface clean we could expose that as different functions on the interface (which of course in implementations would very simply call each other) and then deal with the logic in selecting which one to use in the ZipRangeReader library instead?