Oh I understand that the system Ping talked about had the content distrubuted around the nodes, but it all it did was distribute bandwith / hosting - not the metadata intelligence, and that to me is the most important aspect of decentralization.
-Zack On Wed, 23 Jul 2003, Jason Webber wrote: > Zach - > > I think you're thinking that the DMT is going to be the central data > storage site for all Dean related media; that's not really the purpose > of DMT. Their entire purpose is simply to allow for seamless access to > widely distributed content across all the media nodes - and at a variety > of locations, not just on one centralized server. > > - Jason > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of zachary rosen > Sent: Wednesday, July 23, 2003 4:09 PM > To: Ka-Ping Yee > Cc: [EMAIL PROTECTED] > Subject: Re: [hackers] Dean Media Network > > Well... I am all for starting simple, and scaling things up. But I have > to say - i don't like this design much at all. > > We are designing this network to be distributed for a reason, now would > be > a good a time as any to reiterate them. > * Edge to Edge principal: Distributed networks are much more flexible > and > powerful than centralized ones, period. > * Reed's Law: The more content is tied to communities the stronger the > commmunities are. Reed's law tells us that having many satellite > communities within a large social network you will a vastly more > powerful > network. > * It's sexy: Nobody has created a distributed web network like this > before. We get to be the firsts. It is an incredible opportunity - why > cop out now? > > Yes, the role of tracking the metadata for the media on the network > really isnt that big of a task, so having a central DB do the task > rather than a distributed DB won't kill the whole project :) But i > completly disagree with your observation that a centralized system > is much easier or would save us a lot of time. Every node is going to > have > to host the media anyways. This means every node will have to have a > utility for uploading and pruning media. Then it makes very little > sense > to me to not also assign the metadata to the content on the nodes as > well > and just aggregate like the rest of the network content sharing > functionality. > > I think DeanMediaTeam is great. They are fulfilling a very important > task. There is a very large need for a community organized around the > creation of dean media, and it think they will do a hell of a lot for > this > campaign. I also think they would be the perfect choice to maintain the > global media repository that tracks all the media on the network. > > I don't think they should be the central authority, spoke-and-wheel, > broadcast-center to ALL network dean campaign media. > > -Zack > > On Wed, 23 Jul 2003, Ka-Ping Yee wrote: > > > Hello all, > > > > I had a discussion with Alison about the media module recently, and we > > talked about a story for media syndication that i'd like to air here. > > > > I am also working with the Dean Media Team > (http;//deanmediateam.com/), > > which is coordinating creative talent to produce content in a variety > > of forms (videos, signs, business cards, and so on). > > > > At the moment, i see myself as the bridge between H4D and DMT; i don't > > know of anyone else who's deeply connected to both projects. There's > > a convergence we're approaching that could either turn into a conflict > > or into a nice synergy, and i see my role as trying to help things > work > > out smoothly. > > > > With the Dean Media Team, i'm developing a database to gather URLs to > > the media, with two main functions: (a) to enable people to find > > relevant media in formats and at mirrors that work for them, and (b) > to > > give people a place to work collaboratively on media projects. > > (You may have seen the rough SQL schema i posted earlier on this > list.) > > > > Those two parts -- metadata and collaboration -- constitute the > > technical work for the DMT. The metadata half will store things like > > category keywords, file formats, sizes, bitrates, and URLs to media. > > Sound familiar? That is just what we were talking about building for > > the media module. So we can save ourselves a lot of work by using > this > > metadata database. (In fact, duplicating this work would probably > > generate harmful confusion.) > > > > It seems to me that the DMT picture consists of metadata and > collaboration, > > while the H4D picture for media is about metadata and syndication. > The > > metadata piece is the common part. > > > > The interesting conclusion is that we don't really need to build > anything > > special in order to syndicate media. I propose that we just use the > > existing article syndication functionality. What the DMT database > will > > give us is a persistent URL to use to refer to media items, so viewers > > can go to that URL and find an appropriate format and mirror. Once we > > have persistent URLs, then all you need to do to syndicate a media > item > > is to simply post the URL of the media item in the text of an article. > > Then any stuff we do for articles (syndication, rating, etc.) will > also > > apply to media posts, for free. > > > > I like this solution because: > > > > (a) It avoids conflicts between two projects trying to do the > > same thing in different ways. > > > > (b) It decouples the two parts: the metadata part doesn't depend > > on the syndication part, because it's only about having a > > persistent URL. And the syndication part doesn't depend on > > the metadata part, because you can post a URL to anywhere in > > your article. If people decide not to use DMT for whatever > > reason, no problem -- they can still post URLs to their > content, > > regardless of where they decide to put it. > > > > (c) It's the least complicated. > > > > (d) It's the least work. > > > > Note that i'm not declaring any policy on hosting media content here. > > I think it's important to leave that flexible ("i don't care how you > > post it, just give me a URL"). People will want to host their media > > in ways that are convenient to them because it may be hard to move > > around big files, etc. They can syndicate any URL they want -- if > it's > > a link to a node on the DMT site, then they get the benefits of > metadata, > > collaboration, and a level of indirection in front of a list of > mirrors; > > if it's just direct link to a media file, that will still work, they > > just won't get the added benefits of a metadata repository and won't > > be able to move the file. > > > > I'd be grateful for your feedback on this plan. > > > > Thanks! > > > > > > -- ?!ng > > >
