It's Like Déjà Vu All Over Again
"You could probably waste an entire day on the preceding links alone. But why take chances? We also give you Paul Snively..." — John Wiseman, lemonodor
P2P systems don't need to be totally decentralized, nor will any successful system ever be. It is neither reasonably efficient nor is it desirable from a commercial standpoint. Total decentralization was and is only a goal due to legal issues associated with copyright infringement. Remember, Morpheus didn't break due to technical issues associated with FastTrack's centralization, it failed due to business issues between partners.
The keys to a next generation P2P system that makes money and delights users are subnets, publishing, and service driven apps. P2P has been mostly focused on transport protocols to date. That needs to change. [John Robb's Radio Weblog]
Yes and no. The protocol issues are important to issues of authentication, scalability, reliability, and even routing itself (especially, for example, in the presence of firewalls). It's a bit too early yet to call this a solved problem (but keep watching Ensemble, Spinglass, Spread, and JXTA).
P2P won't really be interesting until there's a workable P2P economy. The only folks I know of who are seriously working on this are either directly or indirectly connected to the ERights project.
9:14:16 PM
What is a peer in P2P? In my view, a true peer can connect to another specific peer at will. Anything else (like what you see today on the P2P networks) is collective BS. I am not a peer on Morpheus or Gnutella. I am a storage resource for a specific file. Today P2P = shared disk. [John Robb's Radio Weblog]
I'm not sure I follow this: this makes it sound as if all P2P needs is for everyone to use dyndns or something so their machine can be looked up and connected to. Unfortunately, without talking about specific applications like file-sharing, it's tough to talk about P2P in a meaningful way—unless you go to the other extreme and start talking about pure infrastructure, which does indeed tend to be the other kind of P2P conversation that takes place.
9:06:57 PM
In the long run the scripting culture has to win. Tightly coupled and brittle interfaces aren't particularly enduring. We also need a protocol which enables people to initially develop simple interfaces and then gradually evolve them to be more adaptive without breaking deployed clients and servers. [Sam Ruby's Radio Weblog]
I could not agree more with this. The software world is becoming more dynamic, not less. We need more runtime tools. Here's some interesting reading along those lines. [Patrick Logan's Radio Weblog]
We need more freedom, that's true. But type freedom the way Javascript has is not the solution. Type filtering is something I'm looking for. In a far from perfect way this is possible in XSLT. For example a template that requires an x element with an a subelement, would have a match="x[a]" attribute. If then later x elements need more subelements, the template won't break. And if the template needs a subelement, say b, you change the match to match="x[a][b]". And then x elements without b will simply not match anymore. There's no "b is not defined" error.
What a lot of people don't seem to realize is that there's yet another ground in the typing wars: languages that don't require you to declare types, but instead infer types automatically. In other words, they have the property of being strongly-typed, but not explicitly-typed. A good many functional languages that are not in the Lisp family have this property. It might be interesting to examine how, e.g. SOAP would be implemented using such a language.
9:00:17 PM
