2010/3/29 Melvin Carvalho <[email protected]> > > > 2010/3/29 Blaine Cook <[email protected]> > > On 29 March 2010 04:28, Carlo von Loesch <[email protected]> wrote: >> > Of course Twitter is not the model - it is completely centralized. >> > The decentralized answer to this is pushing events to the intended >> > recipients as they happen. You can use HTTP POST madness for this, >> > as Blaine Cook considers feasible, or use or design a protocol >> > actually optimized to do this job. There is a reason why chatrooms >> > are usually not implemented by HTTP POST orgies. >> >> Actually, increasingly they are. >> > > Was actually discussing this topic with Henry Story this morning. > > I just want to say that I also think chat over HTTP is not optimal, but > that it *can* be done. > > Take a look at the ape-project chat: > > http://www.ape-project.org/demos/1/ape-real-time-chat.html >
Hmm looks like it's down, right now ... was working this morning ... apologies for that, I'll check the link before posting, next time. > > This is backed by persisent AJAX calls (think of that as what websocket > will look like) and a comet server, over HTTP. > > Just to reiterate, I am not suggesting this as part of a design, I actually > agree with Calro that we'll want a better realtime protocol for chat in the > longer term, but it shows realtime can work over http, if you're prepared to > be a little creative. > > >> >> I'm not the only one advocating this approach. I agree it's not >> optimal, but as you speak of "wisdom" in another thread, I'll >> reiterate that I built one of the largest implementations of a >> "chatroom" ever built, and worried a lot about the inefficiencies >> therein. As it turns out, Twitter is far bigger than when I was >> worrying about these inefficiencies, and still runs on HTTP polling. >> It's appalling, it's horrendous, but developers love the HTTP, and >> most importantly, it's massively successful. So the wisdom I've gained >> is that sometimes the "best" technology doesn't win; more often than >> not, the most suitable technology wins. >> >> And isn't that the most important thing here? Do we want a highly >> tuned race-car of a P2P decentralized network that has no users, that >> concedes to Twitter and Facebook the bulk of users and their freedom? >> Or do we want a successful technology that empowers more people and >> promotes and extends freedom to them? >> >> You're welcome to create something entirely new, but I'd suggest you >> start by mocking up some designs as to how your P2P network is meant >> to work /for users/, and not just geeks. The same applies to the >> usability of the underlying technology as far as your target >> technological audience is concerned (in this case, your audience is >> almost certainly web developers - c.f., GNU Social targeting PHP). The >> technology is important, but the usability and desirability of the end >> result is far more so. Ignore this at your peril. >> >> b. >> >> >> >
