Peer review for new Cloud Assets Module

[Mark Guinn]

I've just create a module that allows some or all of the assets folder to live in the cloud. That's a topic that's come up a few times on this list and is, I think, pretty important in moving Silverstripe forward as a platform, so I'm asking for input - architectural issues, test cases that should be covered, things I haven't thought of, etc. I've only implemented a driver for Rackspace CloudFiles at the minute but the architecture is very easy for others to chip in and extend.

https://github.com/markguinn/silverstripe-cloudassets

There's a "How This Works" section in the README, and the unit tests should explain pretty much what is covered and not covered.

If there's a better forum to post this, I apologise. Thanks for the help!

Mark

[Marcus Dalgren]

Man I need this functionality so bad!

I'm doing the S3 integration ASAP and will let you know how I get on with your module.
Awesome work!

[Marcus Nyeholt]

I've been working on a more generic approach to file handling in SS in general that can make use of CDN storage of assets and themes

https://github.com/nyeholt/silverstripe-content-services

https://github.com/nyeholt/silverstripe-cdncontent

https://github.com/nyeholt/silverstripe-s3cdn

There's a few things been done to better support this in the framework core too

Cheers,

Marcus 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/groups/opt_out.

[Mark Guinn]

Marcus,

This looks great. I checked this out when we were starting our current project but it wasn’t quite as far along then and our needs were for something a little more transparent, due to the other modules we were using. I suspect your module, especially the base content-services framework, will provide a better abstraction in the long run - hopefully being adopted into or imitated by the core assets/filesystem stuff.

My implementation is probably a shorter term measure until the core framework catches up and allows better CDN integration and/or better extension points.

Mark

[Daniel Hensby]

I think what this thread is showing us is that there is a real demand for storing or accessing files through external services. Be it accessing through CDN or remote storage of files.

What we need to  see is an abstraction layer in SS where the File_Backend is not inherently linked to the filesystem as it currently is.

[Nedmas]

I agree with you Daniel. I think this is something that is in high demand and something that would hugely benefit the SS community.

And while I don't want to discourage the great work that Marcus and Mark are doing, however I thought it would be worth asking what people thought about integrating a more generic solution like https://github.com/php-loep/flysystem?

It's just an idea. And I was just wondering what peoples thoughts are?

[Daniel Hensby]

Exactly. It's not about discouraging this work, which is valuable in seeing what works and what doesn't as well as proving there is real demand to be able to do this kind of thing.

However there is desperate need for having a layer of abstraction for "files" and, in fact, SS is pretty close to it given that assets are stored in a DB table. Using something like flysystem could work, but I don't know it well enough to comment specifically. The architecture of a common interface that then uses adaptors (much like Image_Backend does for image manipulation classes in 3.x) would allow a huge amount of freedom (if implemented correctly) to host files through a CDN or remote storage.

[Marcus Nyeholt]

The core bit of https://github.com/nyeholt/silverstripe-content-services/tree/master/code/content is about referring to content in an underlying store-agnostic way, non-dependent on SilverStripe. It doesn't do some things (yet) that are needed (eg listing directories), but provides the core set of file functions needed for SS file management. flysystem didn't exist at the time, otherwise I may have looked at that

[Nedmas]

I figured that was probably the case for you Marcus. The reason I bring it up is for sustainability, abstracting the file system is a sizeable chunk of work (kudos for what you've done), I wonder if it would be better in the long run to utilise something like flysystem so that the SS community can spend as much time as possible on other awesome features?