Forwarding Rene Treffer's comments, and Joe Hildebrand's responses: > > 1. XMPP requires many roundtrips. This could easily be solved, e.g. by using > a client-push namespace with some special semantics (e.g. like doing an > anonymous login on behalf of the user)
It's possible to pipeline a lot of those roundtrips, but you're right this is something for which we need a best-practices document. In practice, if you're going to be doing TLS, the extra round trips aren't *that* bad on most networks. > 2. There are some session problems, like syncing an xmpp user and a web > user. Most sites will like an easy user sharing. This has not yet been > solved. Do you mean from an authentication perspective? There's both SAML and OAuth mechanisms being worked on. With both this issue and the previous one, if you're connected to a local XMPP server at all times and use federation to get to the remote service you want to access, you won't have issues. > 3. Websockets enabled binary pushes. XMPP on the other hand is more of a > protocol framework. It would thus naturally provide a different approach, > and perhaps even solving different problems. I'm expecting that we'll write a XEP like: <message> <data xmlns='urn:xmpp:data:0' encoding='base64'>aGVsbG8gd29ybGQ=</data> </message> <message> <data xmlns='urn:xmpp:data:0' encoding='none'>hello world</data> </message> -- Joe Hildebrand > On Feb 21, 2011, at 12:11 , Matthew A. Miller wrote: > (Apologies for the delay in publicizing; sickness overtook me) > > One of the guerilla conversations at the XSF Summit was about XMPP usage in > the browser. Below is the first documented follow-on. Most of the rest of > the responses were about general acceptance of the concept, hence they're > omission. > > I'll try to forward the more substantive comments soon (and/or urge the > original participants to respond again here). > > > - m&m > > (PS: Originally sent from the "wrong" account; hopefully this doesn't show up > twice!) > > Begin forwarded message: > >> From: Adam Brault <a...@andyet.net> >> Date: February 8, 2011 21:25:58 MST >> To: mwi...@gmail.com, nat...@andyet.net, ke...@kismith.co.uk, >> stpe...@stpeter.im, ral...@ik.nu, mamil...@cisco.com, >> flor...@florianjensen.com, j...@metajack.im, will.shew...@isode.com, >> b...@code-bear.com, nver...@process-one.net, alexey.melni...@isode.com, >> si...@buddycloud.com, joe.hildebr...@webex.com, julien.genest...@gmail.com, >> laur...@eschenauer.be >> Cc: hen...@andyet.net >> Subject: XMPP in the browser -- your thoughts? >> >> Hi, Folks... >> >> So... what do you *really* think about the idea of XMPP in the browser? ;) >> >> After discussions at the XSF Summit this weekend, I feel pretty passionate >> about this idea and want to do what I can to help push the issue at least to >> a point of reasonable consideration. (For those of you who weren't a part of >> the conversations that took place, it sounds as if there is a window of >> possibility for XMPP in the browser.) >> >> As most of you know, I am not a software engineer and I'm not even close to >> an XMPP developer. Also note that I myself don't take ownership for these >> ideas—they belong to people smarter than me. I'm just set on advocating them >> as much as I can. >> >> Will you take a look at what I've written below and provide your feedback? >> (My current thought is to post a variation of it based on feedback to the >> hybi mailing list and to our blog at some point. At Joe's suggestion, I >> submitted a talk to OSCON with the same general topic.) >> >> The kinds of things to consider as you read: What do I have wrong? Where are >> the blind spots? Where does it sound naive? What examples should I be >> pointing to? Is this even a good point—do you yourself think it's a good >> idea? What other arguments do you perceive there to be for and against >> it—particularly in terms of benefits, barriers and objections...? Would it >> be better for someone other than myself to propose the notion? I certainly >> wouldn't take offense at the suggestion. >> >> I very much appreciate your honest feedback and consideration. Don't be >> afraid you'll hurt my feelings—just be as blunt as you possibly can. :) >> >> Cheers, >> >> Adam Brault >> &yet >> >> >> ======================== >> >> Websockets are a terrific idea that suddenly got put on hold this year. But >> perhaps Websockets' stumble sets us up to take a closer look at something >> else. >> >> Giving web developers access to a real transport opens all kinds of >> opportunities in development and leapfrogs a lot of the hacky methods >> currently used to push data to end users. Unfortunately, it's highly >> possible Websockets might be an opt-in feature for the forseeable future in >> some major browsers due to security concerns (among other things). >> >> It makes sense to seriously evaluate the idea of browser-based XMPP. The >> idea isn't a new one, but it's beginning to gain some traction for good >> reason. >> >> It is historical fact and present reality that the Internet as a whole is >> weakened by monopolies and dramatically strengthened by diversity. >> Competition and decentralization makes everything about the Internet better. >> But more than just playing to the web's ideals of decentralization, XMPP's >> federated, flexible, mature and secure nature as a protocol opens up >> enormous possibilities for developers, browser creators, business, and >> consumers. >> >> A few things that browser-based XMPP would help make possible: >> >> 1. Accelerate the growth of realtime/push web applications by providing >> XMPP's deep feature set via JavaScript API that makes XML easier to deal >> with for frontend developers and faster to build off of XMPP's strengths >> instead of continuously reinventing the wheel. >> >> 2. Overcome the last mile of realtime tech which is often ignored—pushing to >> the end user. Things like PubSubHubBub push between servers and services, >> but the getting that same data to the end user at this point is not as >> elegant or straightforward as it could be with XMPP embedded in the browser. >> >> 3. Take federated social networking to the end-user, conceivably allowing >> them to choose network(s) to interact with, rapidly making federation the >> norm in this arena and decreasing the likelihood of one or two proprietary >> social networks to dominate the web. >> >> 4. Enable browser-based authentication, ID and payment to become a reality. >> In addition to speeding up development by commonly centralizing the most >> repetitive problems, the whole Internet basically becomes an App Store with >> a "Buy Now" button baked into the browser—birthing a new industry of webapps >> aimed at consumer-level impulse purchasing a la the various mobile app >> stores. >> >> 5. Revolutionary stuff that hasn't even been dreamed of yet. >> >> Ultimately, I think this type of new browser feature set is so beneficial to >> all parties involved that I think we're looking at a huge increase in the >> Internet economy once browsers begin to implement such a spec. >> >> These (among other things) provide some very good reasons for strongly >> considering browser-based XMPP. >> >> Still, I anticipate harsh disagreement and welcome it. At the moment, I >> actually want to hear why this is a bad idea much more than I want to hear >> why it's a great one. I believe it's worth giving serious evaluation to the >> variety of concerns involved. >> >> In inviting criticism, however, I'd like to make the ad hominem aspect of >> counterarguments moot: I work at a company that has experience with XMPP, >> node.js, and Websockets, and have had numerous discussions around this >> topic, but I myself am absolutely not a software engineer. I'm fully aware >> of my ignorance but generally unafraid of it. :) That said, the notion and >> its possibilities are not my ideas—I'm just collecting thoughts, ideas and >> discussion from smarter folks than myself. >> >> I believe the critical opposing arguments that will be voiced fall into one >> of several categories: >> >> 1. "XMPP sucks for JavaScript developers." >> As I alluded to above, there needs to be a solid JavaScript API for XMPP in >> the browser that means developers don't have to do the pain of working with >> XML in JavaScript. This is an absolute necessity for XMPP in the browser to >> be at all feasible. >> >> 2. "XMPP doesn't scale and doesn't belong in serious high-volume web >> services." >> It is my understanding there's compelling real-life data showing the high >> level to which XMPP can be scaled. I'm not the right person to provide and >> discuss this evidence, however. >> >> 3. "Websockets would be better." >> I think Websockets would be different—better in some ways, for >> certain—though without XMPP's instant depth of features and flexibility. And >> I would hope to see an adoption of Websockets. This isn't either/or. >> >> Thanks for reading and I'm looking forward to discussion. >> >> ======================== >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
