Forum OpenACS Development: Media package ideas

I am working on a new package to allow me to attach media -- images, movies, links, etc. to other content.

Please take a look at the current media package datamodel and comment.

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();

}

https://openacs.org/doc/acs-content-repository/guide/object-relationships.html

I must be tired - I have read this doc page a dozen times - just haven't used the feature recently.

Why aren't you using the content repository. It already handles most of the features you need. It also handles storage a little more easily, allowing file system or database storage of the actual media.

Mark,

There is a movement to simplify the existing attachments package to do what you are suggesting. It's on my list as part of clearning up general comments.

So, in all, storing media in the content repository and using the existing cr_item_rels table to relate the media to an object seems the best way to go.

I definitely want to see this type of solution for future CMS work.

Thanks for the feedback.

Sorry for some of the naming of the tables, I was in the process of moving them to a separate package, and I didn't get everything updated.

When I started working on this I only thought about images and movies, so the name media seemed like it would work, but yesterday, after the datamodel had been sitting around since Sept. 8, I realized that that was kind misleading. A number of places I looked on the internet included pdf and word documents as media, but the point of the package is to attach things to other things. Attachments seemed better, and I didn't realize that there was already an Attachments package.

I need to be able to attach things to any database table row, and I need multiple 'anchor' points per row in many cases. However, the anchor points don't need to correspond to table columns, they can be arbitrarily named.

Although the media table includes a blob column, I have decided to remove that, as I noted. The storage of media objects (I guess 'attachments' is better) is not in the basic tables for the package. The storage could be in the CR, or in the filesystem.

The package must provide direct access to the attachments, images, for instance, need to be referenced in an img tag.

I'll look at the current Attachments package, but it sounds like it doesn't address all these requirements.

I've revised a little the datamodel and included it in a new file. Since there is already an Attachments package, I am sticking with Media. But I'm using the terminology of anchor to refer to the points you can attach objects.

This is much more involved than the Attachments package, because I need to be able to attach to non acs_objects, and to multiple 'anchors' per object.

I'm still considering if I should revise other parts of my main package to use acs_objects where I didn't really want to, and simplify further by only allowing anchors that correspond to the attributes of these acs_objects. There are probably more benefits to this approach.

I was concerned that if I use the 'attach to acs_object attributes' approach, I would not be able to attach to the row, but I could just use the id column for this purpose.

Assuming this approach, would every attribute of every object be an anchor point? Possibly a mapping table from media types to the anchor points would allow you to specify what kinds of media could be attached to each attribute. The mapping table could also include max_size and other configuration parameters for the attachments.

If the CR is used, is there a generic type? Having image, extlink, etc. is a great start, but would I need to hand write a type handler for every specific type?

I'll spend the weekend mulling through the CR again to see what is possible.

The main requirement of the package would be to provide a simple method for the developer to allow users to attach media to other database objects, and to make it easy to display these attachments as links or inline content.

I'll prepare a requirements document to explain the datamodel.

The reason to attach to something other than acs_objects is that, personally I use a lot of support tables that don't need to be acs_objects, which would benefit from media attachments.

For example, some developer might use the list of the states in grouping users. When listing the users, they might want to have a little icon with the shape of the state. The developer could use the media package to associate the icons with the state data. It should also be possible to package this data up for general use.

Another user might be reading the forums and want to provide a link from a post to another thread, or to some relevant document. The forum template could be modified to include a simple tag that would provide a link to the media UI so a user could add the link, or other document.

I might want to allow users to include multiple pictures of themselves, or about subjects of interest. They should be able to visit their workspace and find a link to let them add new photos.

I'm guessing that if I used the CR, my media table id column would have to reference cr_revisions instead of acs_objects. What I am not sure about is that if I have many different media types, how will the other attributes be stored, since they can't all be in the media table?