This project is read-only.

Suggestions for IStorageProvider

Topics: General
Apr 7, 2011 at 3:38 PM


I have been thinking about the API exposed by Orchard.FileSystems.Media.IStorageProvider, and I have some comments about it. I have a feeling that it is exposing too much information, limiting the ability of the implementer to make certain decisions without exposing them. To correct this, I suggest two changes to the interface:

  • Make the "folderName" or "path" and the "fileName" suggestions rather than commands, and
  • Make all editing methods (such as "Create" and "SaveStream") return the public URL of the saved file, removing the "GetPublicUrl" method.

This would give storage providers more control over their implementations, allowing various scenarios such as non-hierarchical storage, database storage or Copy-on-Write, and making sure that any reading methods will be called only with URLs (or paths) returned by the provider itself.

What do you think?

Apr 7, 2011 at 3:52 PM

Yes from what I've seen of the Media system it's all built around on-disk storage.

I'd be interested to hear your thoughts about a replacement media framework we started discussing here and I've outlined in more detail over at:

We're explicitly attempting to separate the source of a media file from the actually ability to process and render it. So media sources can be feeds, file system, database, whatever you like.

I want to leverage as much as possible from the built-in Media system, basically it would provide the default File System Source and hopefully we can feed our system back into the Media Picker in 1.1.

If you have any ideas or anything to contribute then please get involved ;)

Apr 7, 2011 at 6:22 PM

Hello randompete,

I've read your discussions about the media framework, and it looks well thought, but I am hoping to get the input of Orchard's developers on these points, as the IStorageProvider interface is a core one, defined in the framework itself. Your module(s) might use it as well.

Do you think the changes I proposed make sense?

Apr 7, 2011 at 6:52 PM

I started writing my implementation of FileSystemMediaSource and at the moment I only need to talk to the IMediaService from Orchard.Media to discover or store file-based media.

It would have been nice to instead provide various IStorageProvider implementations to pull in media from external sources, but for the reasons you've outlined it's not appropriate; besides the fact that you only appear to be allowed a single implementation. I'm also finding it a bit circular I have to make an additional call to GetPublicUrl every time I get a file detail.

On the other hand, "Storage Provider" isn't really an accurate concept to describe everything we're talking about around "Media Sources"; so maybe the new approach is better anyway. It's inclusive of IStorageProvider but other things as well.

Now, I'm wondering if you're aware of Virtual Path Providers. They're a .NET feature allowing you to hook into the file system at a much lower level than Orchard; although they probably require some Web.config modification to work. But you could look there for some of your requirements.

I'm really not sure what opinion the devs have about any of this; I'd also like some feedback regarding our media ideas, but I'm assuming that right now they're extremely busy getting ready for MIX'11 and Orchard 1.1. Mercurial has been having a particularly exciting time of late :) At this stage I've no expectation of them looking at anything new for another week or two ...

Feb 2, 2012 at 10:01 AM

Another nice addition would be to let the default provider(s) trigger certain events that you can hook (like catch and maybe disallow a delete, get notified when a file gets added, ...)