I’ve got a new version of Rm running on the site now. I hacked up media support, tags, and some random backend features.
One should note that, while I’m not stealing flickr’s code, it kinda makes sense to generate the same size of thumbnails that Flickr does, so I added 75x75 thumbnails for everything.
Media
I decided that I’ve got too much “media” I want to share on the web, and I’ve gotten sick of dealing with the usual way to do things.
The old way was the same as everything else — there’s some files, upload them to your server.
But it turns out that it’s a hundred times simpler to store things with an online editing interface, like a wiki or a blog, because stuff can manage itself. I can post a blog entry and then it can get added to the various places on the site in one action. And the images can have thumbnails for easier preview.
The first, unreleased version of the engine featured an Image object that stored the image directly in the database. Then I accidentally blew away my database and decided that I really needed to make a setup utility for things. At the same time, I got heavily involved in Flickr.
I decided that the problem of storing large media objects, like images and video and sound, was different than solving metainformation. So even though storing the image directly in the same database makes things conceptually simple, I decided to split off big blobby objects into a separate subsystem. So this makes for a fundamentally new way to store “things” in the site.
Basically, I figure that if you would want to run Rm on a really popular site, you are going to want to split content out between machines and the page content is going to have different properties than the binary blobby stuff.
At the same time, I also realized that Flickr and similar sites are here to stay, so I might as well use them to my advantage. So I split things up so that there’s a generic image class which then has a child for flickr images and for local images. Kind of like how Vox works.
The root cause of me adding this feature, of course, is that my music and wireheadarts.com are still written with older ways of doing things and I wanted to bring everything to the new system. I did find that the music situation has gotten even better and more trouble-free than before. See, in 2000 or so, the MP3 revolution was well along on its course, so it was basically guaranteed that if I sent you an MP3, you could play it. Now, not only is that true, but you can use a Flash player so that it’ll just plain work to have it playable via a website.
I’m intentionally avoiding too much video support right now. The problem with video is that it’s really really hard to get seamless. You have to transfer a lot of data up to the server, transcode it to flash video, and then serve fairly huge files. It’s not impossible, I just prefer to leave that work to Youtube and Vimeo for now.
Making room for the future
Tags are enabled and I wrote them in a curious way.
See, I don’t like to talk about really out there ideas until I’m done with them. They are either really crazy and dumb, which means that I may not want to talk about it later, or they are brilliant, which means that I want to wait till I can get a proper demo to show off.
Now, there’s one thing that’s driving me batty. For some reason, I’m always running up against the rel-tag microformat specification. First, I wasn’t using directories on Wireheadarts.com, which meant that things weren’t valid. Now I’m faced with needing to fit the rel-tag model into the URL model that I’ve set up.
I decided that, since the ltree module that underlies the implementation of the paths is very restrictive about names, I might as well steal one of those characters to create the notion of a “mount point” so that a single node can service many virtual “directories”, so I created a “path separator” object and the code to unroll that.
The thing is, the structure that underlies the “tags” right now will also let me store other interesting data and do other interesting features.
Ruby’s cgi library
One kind of obnoxious point about Ruby’s CGI library. If you use it normally, without uploading files, all of your parameters are inputted as strings. However, once you switch to multipart form encoding to upload files, all of the sudden everything is either a temp file or a file string. Which then means that all of my parsing code that was calling .to_s() on the form variables suddenly started returning a # character.
This drove me batty until I figured it out. Thankfully, I wrote a function that would use duck-typing to see if it was a file-ish object or just a string and react accordingly. But it’s still obnoxious that nobody bothered to write a to_s().