I don't see how that data model allows you to specify that the media is attached to anything - or would you expect that to be done elsewhere?
After my time in the midgard php CMS, i have gotten used to having media arbitrarily attached to any object - and for CMS style applications it's "a good thing".
My feedback would be, rather than having a media package, which seems somewhat limited, why not an "attachment" package - so you basically store a blob + metadata and link it to an acs_object.
Seems basically the same, but caters for every possible circumstance. Of course you would specify standard metadata to store for common media eg/ mime type for everything & height/width for images.
Thinking objectly (and ripping from midgard shamelessly), the object & api would be something like:
Class attachment {
var $id;
var $pid; // context in acs speak
var $score; // for forced sort orderd
var $name;
var $title;
var $location; // midgard uses file-based blobs
// we should store the blob in the content repositary
// does CR let us choose db vs. file system on a per blob or per package basis?
var $mimetype;
var $sitegroup; // package_id in acs speak
var $author;
var $created;
function new();
function delete();
function update();
function get();
function open();
function serve();
function stat();
function listparameters();
function parameter();
function searchparameters();
}
It works pretty well - the parameter functions use a system wide parameter table and allow for unlimited arbitrary key/value pair meta data to be applied, gotten and searched. In addition, the cms systems that use midgard apply standard metadata tags for things like image height/width.
