Re: Abstract file Storage interface to store files in different places like local fs, cloud services, sftp, amazon s3...

[mark_story]

Isn't this just really really fancy stream_wrapper support? http://ca2.php.net/manual/en/intro.stream.php  By using and extending stream_wrappers you can open files on basically any protocol. As in http://ca2.php.net/manual/en/intro.stream.php

I'm not saying its a bad idea, but is there a reason we shouldn't just be providing an easy way to create stream wrappers that work with fopen() and friends?

-Mark

On Thursday, 31 May 2012 17:30:59 UTC-4, burzum wrote:

I would like to propose an abstract interface like Gaufrette for the core. I've written already a CakePHP plugin that wraps Gaufrette into a nice cake plugin.

I'm not saying we should implement all the storage adapters in the core, they can become an external project like the additional database sources or 3rd party cache engines.

The idea is to acces any kind of file storage device or service through the same interface. This would make it easy to work with them and keep the code well re-useable and DRY.

The storage interface itself could work similar as the cache engines. My plugin already implements a singleton StorageManager that can load adapters as needed and access them through a config key.

Another advantage of the interface would be a smooth migration between different storage systems:

StorageManager::adapter('AmazonS3')->write('/in/my/bucket.foo', StorageManager::adapter('Local')->read('/my/file.foo'));

[burzum]

What I suggest does not exclude that the underlying code can use the streamwrappers. Actually I have not reviewed all Gaufrette adapters to see how they do it.

[Steve Found]

Is there a published design document for CakePHP 3.0 ?

I have seen the calls for the community to get involved where possible,
but this is pretty hard to do without a design document. With large
pieces of work such as the Model layer returning objects as well as
arrays for example, it would be pretty much impossible to estimate the
time and knowledge needed for a requirement without one.

Personally, I would like to get involved, but without knowing what is
required and how it all fits together it is pretty hard to gauge what I
should be putting myself forward for, if anything :)

Steve (Ratty)

[Ratty]

I am sorry, I have no idea why this came out as a reply ...  is it possible for someone to move it ?

[mark_story]

Part of the problems with design documents is that they can take as long to create as writing the code + tests.

As of right now there is no design document for the model layer as not much work/planning has been done on it yet.  But I think before any serious work is started on it, there should be some sort of proposed API and feedback is collected on that proposal.  Without that its going to be hard for many people to become involved as not everyone will have the time to review commits and branch differences.

-Mark