tag:blogger.com,1999:blog-5274051535398117366.post4834675991743232383..comments2008-12-09T13:35:17.305-08:00Malte Ublhttps://profiles.google.com/116910304844117268718noreply@blogger.comBlogger3125tag:blogger.com,1999:blog-5274051535398117366.post-91285377876190052032008-12-09T13:35:00.000-08:002008-12-09T13:35:00.000-08:00One might be able to reduce the problems caused by trust issues by doing redundant calculations on multiple peers.<BR/><BR/>In the end one could apply all of the concepts used in p2p programming like distributed hash tables to allocate suitable clients for certain tasks or certains subsets of data.<BR/><BR/>One of the most interesting aspects of this technology is that we are abusing Google's ressources to upgrade clients to something that can be contacted like a server. This could be very useful for all kinds of applications.Maltehttp://www.blogger.com/profile/14948805318873322781noreply@blogger.comtag:blogger.com,1999:blog-5274051535398117366.post-61949341087002200502008-12-08T22:18:00.000-08:002008-12-08T22:18:00.000-08:00You could also integrate this into google gears processes, so that whatever someone happen to run as a process will be distributed in the 'bounce cloud', transparently. Build it and they will come :)Peter Svenssonhttp://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-5274051535398117366.post-699717372402111442008-12-08T21:05:00.000-08:002008-12-08T21:05:00.000-08:00Why pi? We could also try to calculate 42. Or just wast power to tuneup the clima change. <BR/>The question is still what to do with this mass of cpu cycles. Which are also very fragmented. And there is no realy control about the packaging/livetime which will increase the server turnarounds.<BR/>Looking still for a useful application.Menohttp://www.blogger.com/profile/10185941087165782162noreply@blogger.com