Saturday, July 05, 2003

AOL is testing their weblogging tool   BuzzMachine.  AOL is testing their weblogging tools. [John Robb's Weblog] 12:23:19 PM  comment []       Don Park's Thoughts on Blog API My Thoughts on Blog API. First de facto standard Blog API was Blogger API by Evan Williams.  It was naive in design and had some design peculiarities like appkey puzzled others, but it worked.  Evan's "experimental" disclaimer lost its merit when his API was taken up by others without him complaining loudly about it. Dave Winer then designed MetaWeblog API to supplement Blogger API with some notable overlaps in features.  MetaWeblog API is a classic example of 'embrace and extend' strategy which has many benefits as well as many problems.  One such benefit is taking of initiative which is the opening note of many war songs. Both Evan and Dave had the opportunity to remove the danger of confrontation when MetaWeblog API was being designed.  Unfortunately, neither did so.  In fact, both aggrevated the situation by Dave not supporting appkey parameter from MetaWeblog API and Evan starting work on Blogger API 2.0. I think both Dave and Evan are responsible for the mess we have today and I see little chance of a universal Blog API emerging for a while.  If I had the power to dictate things, I would have the Echo project adopt the union of Blogger API 1.0 and MetaWeblog API as Echo API 0.0 and extend it as needed without breaking backward compatibility. Will everyone involved sacrifice their prides, ideals, and needs for the good of all?  Maybe, just itty bitty miraculous maybe. [Don Park's Blog] 10:12:08 AM  comment []       IRC chat about ECHO content with Ken MacLeod Ken MacLeod and I met on IRC chat yesterday morning to discuss content in ECHO.  I found it fun and informative to chat with Ken as we discussed what we thought ECHO's definition of content is now, may be leading and where each of us thought the strengths and pitfalls may be in it's present meaning. I have summarized the conversation below: General ECHO will support content beyond what RSS supports today ECHO is not just a rewrite of RSS "use the best practices of the web, so that doing what we do now works in the future for things we're wanting to do but can't" the Motivation page presently addresses the wrong issue ECHO editors with writing spec skills needed soon Will drive the conversation Need to impartial Adds structure to the present "ECHO WIKI" conversation Approve the editor based on their faith in their ability to perform No specific spec to point to could be cause of some confussion Driven by "ECHO the communitry WIKI" Community hasn't stated to talk about ECHO spec editors? nor requirements or goals/best practices Discussed our views of "the meaning of link" Ken: The meaning of <link> in a feed is a link to the entry on the weblog/site's host, that a user can click to "get the full story" it's specifically *not* content to be presented by an aggregator/reader if a publisher wants a user to be able to *also* view content within their aggregator/reader, then they provide a <content> even though it may be pointing to a video entry, the link may (and likely usually is) a link to an HTML page that *has* a video embedded in it <link> points back to the publisher's website in the context of how the entry was published on their website it's how a user visits the website to see the content in the website's presentation, and to navigate around the publisher's website from there Me (Harold): Photos display in html. Makes sense for photos but how about video and audio. This would just be a link to a html page with the same link With audio and video you send the file directly or you send a file that triggers the plugin or player that the mime type is coming But in either case its a special kind of a link Browsers are image viewers by design As you can see link could have misinterpeted meaning when it refers to audio and video, Is it a link to a html file containing the link and other information about post or the file itself We also looked at and discussed some examples of audioblogs (googling of audblogs) and picture blogs (picdiary). Moving forward What happens when we're more mobile and we don't always see or write? When the words content and link are used with no prefix or context it put limits that cause confussion with their literal meanings. exactly! that's the cornerstone of "cleanly and thoroughly specified". how would you preface or set the context for these definitions? "feed" should not be taken to be synonomous with "weblog" since this isn't a paid-for effort for almost everybody, there's no one to appoint or make responsible for doing certain things. us, people, have to identify issues and volunteer to correct them. there's "no one else" who "should" be doing those things. Other possible types of content in ECHO: http://www.intertwingly.net/wiki/pie/ComponentBlog and http://www.intertwingly.net/wiki/pie/AdaptiveBlogosphere. The content model has to continue to scale and not become frozen. 9:14:05 AM  comment []       Sony Image Station with MetaWeblog API Sony Image Station with MetaWeblog API. Hirata just demo'ed an experiment we did with Sony. It's a moblog gateway. It receives email from a cell phone with a photo attached. The Sony team make an XML RPC metaWeblog API interface to Sony Image Station. We take the picture, talk to Sony Image Station using metaWeblog API and post the picture in a photo album. Then the gateway talks to Movable Type using the metaWeblog API to create an entry with the thumbnail from Image Station that clicks thru to the full picture on the Image Station site. The text and the title get entered into Movable Type and the category is pre-set. We are using the metaWeblog.newMediaObject which Movable Type current supports to send the images. Please support this standard so photo sites can use the API. We'll continue doing tests with the research group and hope to do some syndication stuff soon. ;-) This is not a product and is really just an experiment. I'm hoping more and more groups in Sony start looking at the open standards and that the open standards people start thinking photos, video and audio as micro-content. Totsuka-san from Sony CSL had an interesting comment today. He said that pictures are attached to email as second class citizens and the text is still the core of the data. I think the idea is to try to get multi-media micro-content to be more important. ;-) PS I don't have a URL for this since we have only received an OK to demo it at the conference. Stay tuned. [Joi Ito's Web] Sounds a lot like the AudioBlogging Gateway.  It's really the same concepts and principles used with photos instead of audio files.  There is no reason why the AudioBlogging Gateway concepts and principles couldn't be united to do many multi-media types such as audio, video and photos in one Multi-Media Gateway.   I think it would be great if we could all work together on this in the open. That was my goal when I published the AudioBlogging Gateway idea on my weblog in early April. 6:23:28 AM  comment []

© Copyright 2003 Harold Gilchrist. Last update: 8/2/2003; 6:15:27 PM. This theme is based on the SoundWaves (blue) Manila theme.