Re: [syndication] Cross-Site Unique ID Formats? And ID Debating...

["S. Mike Dierken" <mike@knownow.com>]

There already is a pretty good way to do this:

/dierken.com/my_thing/my_id/whatever_i_want

The VALUE of the ID isn't important, its the NAME.
Everybody gets hung up on the URL used to retrieve something as the only ID.
The 'location' value is misleading. Use some other piece of meta-data. Like
newsgroups and e-mail has Message-ID. Most asynch system have message
headers for unique id.

How things are combined into one large list is much more interesting
problem. Take a look at how Ohaha (a p2p thing) does stuff. Imagine a single
DB table. Each column is a 'key' - but the behind-the-scenes index for that
column isn't on one central server. The index is scattered over a set of
machines. Each index is on a different set of machines. You ask the machines
that you know about & they tell you what they know, plus what their
neighbors know - common p2p stuff. The trick - the 'worse is better'
approach here - is that you don't get EVERY record, but you get enough to do
your job. Don't worry about the time to get each and every record. The fact
that you can get a large number of records from an astronomically huge
database is the cool part. For example, in music searches, people don't need
to know every ocurrance of Johny Cash's songs that are online, just enough
to pick one to listen to.

mike

----- Original Message -----
From: "Morbus Iff" <morbus@disobey.com>
To: <syndication@yahoogroups.com>; <rss-dev@yahoogroups.com>
Sent: Monday, February 26, 2001 6:10 PM
Subject: [syndication] Cross-Site Unique ID Formats? And ID Debating...


> >> Again, does our current purpose scale well? Can we editorialize one
million
> >> rss feeds, checking for all possible aliases, defects, user idiocies,
and
> >> so forth, while still giving ourselves time to read the damn feeds that
> >> we're programming software for?
> >
> >It certainly may not scale, but even if it doesn't it's something that's
> >doable and useful now, and can hopefully grow into something that _can_
> >scale.
>
> Ok. Say we all agree that "major providers of rss feed listings will use a
unique id architecture", then how should we handle it? Say XMLtree wants to
keep their list going, I want to make a list, and Barr wants to keep his
individual list going.
>
> How, how, how do we combine them all together into one massive list? We
certainly don't need duplication of effort. And what if Winer doesn't want
to jump in? How do we handle those who don't join? Do we?
>
> What if we did unique IDs based off "epoch seconds,list id", such that if
there were three providers numbered 3, 4, and 5 and they each added a
channel at the same exact moment in time, it'd be something like
"91374293,3" and "91374293,4" and "91374293,5"?
>
> I still, to be honest, don't see any compelling reason to use unique ids.
Sure, it may be good *now*, when the world is relatively small and meager,
but why waste the time worrying about them if they're *only good enough* for
this point in time?
>
> The words "hopefully grow into something that can scale" do not put me at
ease. We shouldn't hope something scales, we should make damn well that it
does. 'Member Gnutella? (and I'll ignore any comments about "well, hey, he
said it would only handle 300 hosts")...
>
> --
> Morbus Iff
>
>  Disobey has been mentioned in The Netly News, Internet World, ABC News,
>    Bruce Sterling's Dead Media Notes and many more. Microsoft and 3Com
>   ripped us off also... that's GOTTA mean we're important. And hell, we
>   got a rise out of Playboy! With sections that have nothing to do with
>     the others, you'll like at least one thing. No, really. Go there.
>
> -07--- <\/> ---- <http://www.disobey.com/> ------- Bad Ego, Any
Notice ----
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>