-
Notifications
You must be signed in to change notification settings - Fork 11
Use case asset management
Suggested by Siderea, who observes that Asset Management is a popular application of FileMaker. Since it allows relatively arbitrary data types, it is very useful to be able to stick random assets into it, and use the system for organizing them. It might be very useful to do this in Querki.
She's right that this is conceptually a good fit for Querki -- the ability to define arbitrary metadata Properties, manage access, search, create reports and do on-the-fly queries all make sense here.
The issues here are entirely practical. While we are building image storage in from the beginning (because you really can't do a serious wiki without images), we haven't architected this for arbitrary data storage. Some file types are big (some are huge), and you need major server farms for that. Our business plan doesn't have a way to deal with that yet.
Also, the legal dangers are quite real. Two problems are immediately obvious. On the one hand, as soon as we allow asset storage and sharing, we will be used for piracy. (The only reason I don't expect that to happen immediately with images is that we're simply too expensive to make economic sense for the typical pirate, who has cheaper options.) That makes us a DMCA target, and we'll have to spend time and effort handling that. And there's the child-porn danger if we become popular for asset sharing.
So actually storing the assets ourselves is problematic. It may well make sense in the medium term, but not until we have the resources to do it properly.
All that said, in the nearer it is possible that we could use Querki to help manage assets that are stored elsewhere. Say, for example, that a user is logged in with Google credentials. There is no good reason we couldn't build fairly good integration with GDrive and YouTube, where the user can store documents and videos on Google and use Querki as a wrapper to organize them. We'd want to do this for as many storage providers as is practical, so folks could choose what makes sense for their requirements.
In this model, we'd probably have a concept of an incoming storage API -- some relatively neutral glue to work with external storage providers. When you want to add an asset, we'd pop a window to the third party provider, let you upload the asset, and get a handle back to it. (This is a gigantic handwave, of course, but it's roughly what we'd want.) You'd use Querki to manage metadata around that asset, and would be able to see the asset in the third-party interface in a frame or such.
With that concept in place, it then might make sense to do a deal with one or more of the medium-size storage providers -- ideally somebody like Box that has a reasonable concept of access control and privacy. (Since security will be essential for a number of the likely use cases.) We'd work with them on a single-sign-on scheme so that a user can buy memberships to both services, and use them together to get a relatively well-integrated environment. With a good enough integration with the right partner, that might even make a decent long-term solution.