[RFC] Reboot Gaufrette

[akerouanton]

Milestone: release v1.0.

Current situation

• Architectural problems
  • Metadata badly handled or not at all (see #108)
  • Unable to use big files / Performance issues (see #252)
  • No real exceptions, only bad return values like null or false (for reference #400, #395, #383) (fix: #497)
  • Inconsistencies across adapters for keys / listKeys methods (see #344)
• Use of unmaintained 3rd-party libs
  • ~mongo extension has been superseded by mongodb extension (+ mongodb/mongodb php library)~ (see #460)
  • google/apiclient has been deprecated and superseded by google/cloud (see #427)
  • guzzle/guzzle:~3 still used due by aws/aws-sdk-php:~2& rackspace/php-opencloud:~1 (see #426)
  • ~aws/aws-sdk-php should be upgraded to v3~ (see #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 #426)~ (see #478)
• ~Deprecate outdated adapters~ (see #464)
  • Cache adapter should be refactored/deprecated/superseded by a PSR-6/16 compliant adapter
• ~Leverage adapters tests~ (see #465)
• ~Stale PRs~
  • ~KnpLabs/Gaufrette#362~ (see #491)
• ~PHP7 not supported~ (see #458)
• ~Old PHP versions supported (5.4 & 5.5)~ (see #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?