Recovered from the Wayback Machine.
John did respond, in his comments, to my query ,in his comments, about Radio and P2P:
I need a real P2P system to pull this off. Something that can go through firewalls and NATs. Unfortunately, most P2P systems are run by people that are only interested in Napster-style file transfer (essentially a file pile). There is more to this: apps and Web Services.
Appreciation for answering, but one request: don’t go there — don’t go with the limitations of P2P as an answer to the question of P2P expectations in Radio. I can point out more than one application that uses P2P based technologies and whose focus is not based on file manipulation, starting with a mainstream app John probably knows — Groove.
What does Userland want from P2P? Web services imply a server, which implies a traditional approach to serving application needs. Been there. Done that. Next page, please.
If you’re talking publish and subscribe, now we know we’ve been there and done that. Can anyone say “channels”? The technology is neat and seems to be coming into its own — again — but how P2P is this? Isn’t this dependent on a Radio cloud handling the intermittant connectivities of the individual Radio installations? Just as Groove does within its cloud?
Really, with clouds like these, I’ll never have iron-poor blood, will I?
The technology is neat and important and a real step in the right direction, but I don’t think this is what John was talking about. Or is it?
What do you need from a real P2P System, John? If you articulate this, you might find there are people out there with an answer. But we can’t take a shot if you don’t ask the question. Given the right information, we’d enjoy the opportunity, you’d enjoy the opportunity, we’d all learn from the experience, and we’d all have fun.
And we might even come up with some interesting ideas in the process.
