[RFC] Reboot Gaufrette

[akerouanton]

Milestone: release v1.0.

Current situation

• Architectural problems
  • Metadata badly handled or not at all (see Flawed metadata support #108)
  • Unable to use big files / Performance issues (see add localKeys to Local adapter #252)
  • No real exceptions, only bad return values like null or false (for reference Google cloud Storage - unknown bucket #400, Update AwsS3.php #395, Exception during write operation on S3 are not returned, we have false instead that doesn't help. #383) (fix: [1.0] Use exceptions if error(s) happen(s) #497)
  • Inconsistencies across adapters for keys / listKeys methods (see Inconsistent return value from Filesystem#listKeys() #344)
• Use of unmaintained 3rd-party libs
  • mongo extension has been superseded by mongodb extension (+ mongodb/mongodb php library) (see Replace mongo with mongodb ext #460)
  • google/apiclient has been deprecated and superseded by google/cloud (see Adds adapter for Google Cloud Client Library  #427)
  • guzzle/guzzle:~3 still used due by aws/aws-sdk-php:~2& rackspace/php-opencloud:~1 (see aws/aws-sdk-php v~2 dependency #426)
    • aws/aws-sdk-php should be upgraded to v3 (see Upgrade aws-sdk-php to v3 #457)
    • rackspace/php-opencloud should be upgraded to v2
• Lack of maintainers
  • Find a way to to bring attention on tasks/issues that need some love
• Needs coherence across adapters, e.g.:
  • Adapters should not be responsible for opening connections (see FTP adapter)
• No real dependency in composer.json (makes it harder to use) (see aws/aws-sdk-php v~2 dependency #426) (see Create meta-packages for maintained adapter #478)
• Deprecate outdated adapters (see [RFC] Deprecate outdated adapters #464)
  • Cache adapter should be refactored/deprecated/superseded by a PSR-6/16 compliant adapter
• Leverage adapters tests (see Run as much functional tests as possible on Travis #465)
• Stale PRs
  • Provide mime type through AwsS3 adapter #362 (see Provide mime type through AwsS3 adapter #491)
• PHP7 not supported (see PHP7 compatibility #458)
• Old PHP versions supported (5.4 & 5.5) (see Remove support for php 5.4 & php 5.5 #459)

Solutions

For the lack of required dependencies:

1. Don't split right now: carry on with only one repository.
   Good point: Easier to enforce coherence & architectural changes
   Downside: Harder to give maintainer access to community members

2. Split across multiple repositories.
   Good point: 3rd-party libs would be required, not suggested / Easier to give maintainer access to community members.
   Downside: Hard & time-consuming task / Harder to have a complete overview of Issues & PRs / Needs to split doc too

3. Create as many repositories as adapters with only a composer.json requiring the main repo and 3rd-party libs (best of both world).
   Good point: 3rd-party libs would be required too / Don't need to split doc across multiple repos / Easier to enforce coherance & architectural changes / Easier to have a complete overview of Issues & PRs
   Downside: Harder to give maintainer rights to community members (compared to solution 2)

For the lack of maintainer, the solution will mostly depends on the answer to the previous problem:

• In case of splitted repositories: we can give maintainer access to any community member eager to maintain given adapter(s)
• In any other case: create a list of maintainer(s) for every supported adapter and use an issue/pr template which ask people to ping given maintainer(s)

[stof]

I don't think PHP 7 is unsupported (except for some outdated adapters, like the Mongo one as it uses an old extension).
The fact that Travis does not run tests on PHP 7 is a CI issue, not a compatibility issue.

[gquemener]

What about keeping one repository for contribution and auto-splitting it into read-only repositories (one for the core and one for each adapter) ? The splitting script used on symfony/symfony was OSed but I don't know where it is.

Another idea would be to look how npm @ mecanism is working and see if the same behaviour exists on composer.

[stof]

@gquemener the low-level tool is open-sourced at https://github.com/splitsh. But the full splitter is not open-source (you could request Fabien to run it for you though, as he already does it for other open-source projects).

The npm @ mechanism is a way to namespace packages. Composer has it since day 1 and requires using it since years, as packages registered on Packagist are required to use a vendor namespace.

[akerouanton]

List of referent maintainers:

Adapter	Referent
AwsS3	@NiR-
AzureBlobStorage	@NiR-
DoctrineDbal	@PedroTroller, @NicolasNSSM
Flysystem	@nicolasmure
Ftp	@fabschurt
GoogleCloudStorage	@AntoineLelaisant
GridFS	@NiR-
InMemory
Local
OpenCloud
PhpseclibSftp	@fabschurt
Zip

• Those maintainers should be assigned to issues/PRs for given adapters, but they are not meant to be the only maintainer(s) to work on those adapters.
• Other maintainers can also assign issues/PRs to referent maintainers

[burci]

Is there any chance to also merge https://github.com/K-Phoen/gaufrette-extras as mentioned in #246 or implement something similar functionality?

[dkarlovi]

You should also take the chance to review the API. For example, keys() should really take an optional glob pattern, as I've discovered implementing #486. In most cases, you don't want to fetch ALL of your keys.

[akerouanton]

@dkarlovi There's also listKeys() method from ListKeysAware interface, and it takes an optional pattern. Both methods exist because some storages don't allow to search for a specific pattern. But I think the current implementation is cumbersome. IMHO it would be better to remove keys method, merge ListKeysAware into Adapter interface and let adapters unable to list keys for a specific pattern mimic needed behaviors.

But I agree: we need to overhaul current API! We'll do it in coming months.

[teohhanhui]

There's no option to just migrate to / merge with Flysystem?