Blogging 2G: Does it need a Media Management Gateway?
By Harold Gilchrist
There has been a lot of "blog talk" this week about media management as it pertains to blogs.
Let start this looking at the main points of Brent's of inessential.com request that started this thread:
- An extension to the various weblog APIs that I’d love to see would be easy image uploading.
- Not just images, but movies, Flash files, etc.
Brent's response after the introduction of the metaWeblog.newMediaObject by Dave Winer.
"Exactly what my users want is to be able to select a picture, have it get uploaded automatically, and then have NetNewsWire automatically generate the img tag (or whatever) to link to the object.
This method enables that. I can't think of anything I'd change.
Of course, one might in the future consider additional methods -- it would be nice, for instance, to get a list of media files already on the server. But one thing at a time is best. This is the important first step."
If all you want to do is upload a few image files uploading to the weblog server method would suffice.
The real question is as some bloggers move past what I'll call "light media types" is the weblog server the best place for the media files to reside? And if it's not, what is the role of the the weblog server in this model or is this really an interface issue between the media server and client apps?
It's my opinion as we move and scale our blogs toward other media types (both dynamic (live streaming) and static) a separate media management/gateway server is the way to go.
I myself store my blog's media files, audio and images today on a separate server and just embed the necessary html to point to the media on the media server (which today is just a html server I use just for media). It is not that this method is not supported today by weblog servers it just that easier methods and tools could make this process more productive and available to other users.
I would like see the media management server also be a two-way gateway. It should allow the user to send directly media objects from cell phones. PDAs, PCs (stationary and mobile) as well as communicate the media object's presence to networks like the web, RSS, P2P and other networks.
The challanges here for an open API are a plenty:
True. Doesn't make any sense if your serious about doing media beyond images.
The only job of the weblog server should be to contain the html that points to the media object in the post and publish the metadata to the RSS file (and maybe some light media files). Just as the job of the weblog will not be to create and edit the media type, as there are tools designed to do that.
With the use of modules in RSS 2.0, we can enhance the metadata to further describe the media type in the post. For static objects like stored images, audio and video the weblog could contain features like media rolls that point to say the last 10 audio files that have been stored on the blog. This may make sense as keeping a busy blog can easily bury the media files. Another feature would be a media search interface to the blogs management system that allows for quick searching.
By using different interfaces to the media management system. Just as we have interfaces today to other's weblogs through a simple interface such as RSS, we can interface to the media server using similiar ways. Also, there is no reason for all of our media objects to reside on one server. I can see the time when an blogger attending an event would choose to use the event sponsored server based on access speed to the media server supplied by the event sponsors.
Marc's Voice -> How 'bout this:
- an open source media management system written in Apache Cocoon?
- it looks like an XML storage cloud, object store. It could map to the Userland XMLStorage system and other existing storage systems
- it would hold object attributes (obviously), and a pointer to the actual location of media - which practically speaking could be on your local hard drive, your own storage cloud, on some other device in your home, or at school, the office or practically anywhere else. This media could also be streaming media or one of those whacky Rhapsody files that only download 99% of the file, and stream the last 1% on playback
- this would enable bloggers to share each other's images, audio and video and in general, create a sandbox for media fun
This sort of media management system could be accessed from many different kinds of blogging tools, on-line communtiies or other web services or web apps. As long we we all can share the media, all of our goals will be fulfilled.
I believe that Macromedia had something to do with Apache Cocoon and it's XML - so that should be cool. Open APIs - for everyone to use!
Mitch at RatcliffeBlog: Business, Technology & Investing comments: -> Jeremy's suggestion that the files be encapsulated in HTML but reside somewhere else off the blog is absolutely the right way to deal with the problem. The question is how to meta-tag and facilitate the integration of non-blogged material into a distributed a/v distribution system. Marc's got some of the keys to this puzzle....
Looking forward: Blogging 2G
Blogging 2G will include cell phones, PDAs, Notebooks and other devices that can be 2 way on a network that connects to the Internet and back to the blog someway. Today it is using GSM/CSMA and email with cell phones, WIFI and TCP/IP with PDAs and notebooks and tomorrow it will be new devices with other networks using web services with XML-RPC and SOAP.
|| © Copyright
4/6/2003; 3:00:40 AM.
This theme is based on the SoundWaves
(blue) Manila theme.