Hi, It may not be a good time to back to this very old thread while everybody is waiting for the winner announcement. But I want to thank for Dan's explanation.
However as we can see a lot of apps submitted use Gtalk service extensively, and require Gtalk account login, I wonder why not get XMPP included in Android core image under category "disabled now for stabilization purpose"(I see this somewhere in document, but not quite sure what exactly the meaning is), so that leave a hope in case someone developed or something else good jumping up later on. And this does not impact the current Gtalk API. Just a thought. Jeff, have you taken a deep breath yet? please show up in the community and help shape it, now its quite heat here. On Tue, Feb 26, 2008 at 12:46 AM, Dan Morrill <[EMAIL PROTECTED]> wrote: > At the risk of re-opening an old thread, here is some additional > information on why GTalkService is not using standard XMPP: > http://mail.jabber.org/pipermail/standards/2008-February/018015.html > > The short version is that standard XMPP, used as an always-connected > service the way it's being used on Android, is a large drain on battery life > and bandwidth for mobiles. The custom GTalkService addresses those > limitations for now, for our specific purposes. A mobile-optimized XMPP > standard (that's now being discussed by the XMPP folks) needs to exist > before an efficient, general-purpose XMPP service can be implemented. > > - Dan > > > On Fri, Feb 22, 2008 at 5:31 AM, JMcA <[EMAIL PROTECTED]> wrote: > > > > > Ah...good question. > > > > I don't know if the gtalk servers are stricly XMPP compliant. If > > they're not, I would hope Google would fix that, but that's a bit off- > > topic for this forum. :) I do know that they're at least pretty > > close to being XMPP compliant and that XMPP compliant clients will > > work with the gtalk servers pretty much without problems. I know I > > haven't found any way in which the gtalk servers are not XMPP > > compliant...though there are some ways in way they play fast and loose > > with the *spirit* of the spec (I gotta say...appending random bytes > > onto the resource string of connections is *really* annoying, for > > example), I think they adhere to the letter of it quite well, at least > > from what I've been able to determine. > > > > The impression I got was that they're talking about doing this binary > > protocol for android for efficiency reasons, and supporting that on > > the gtalk servers in *addition* to the current XMPP connection method. > > > > From the beginning, gtalk has talked about supporting "client > > choice" (I think is the phrase they used)...where you can use many > > different client software packages to connect...basically anything > > that supports XMPP. The only sane way to go about that is to try to > > keep the client connection code in the server adhering to the standard > > as much as possible. And that seems to be what gtalk has done, in > > general. > > > > As always, I could be wrong. > > -- > > Jeff > > > > On Feb 21, 9:17 pm, Bobby <[EMAIL PROTECTED]> wrote: > > > Jeff you said that you'd like Google to make their gtalk servers the > > > default servers for the desired built in XMPP standard-compliant > > > android libraries. I think Dan said that the gtalk servers have never > > > been vanilla XMPP (i.e. they're customized). Sounds like their options > > > were to either update their gtalk server software in the short term > > > (possibly a major task, affecting many users and projects), or, if > > > that were not an immediate option, to rename the existing Android XMPP > > > libraries to indicate that they're not standard. They opted for the > > > second option and it's hard to judge that decision given that we don't > > > know the internal factors that motivated it. > > > > > > Why not build and host vanilla XMPP servers for Android exclusively? > > > Maybe they understood that that was more the place of a community led > > > effort? I don't know. > > > > > > Bobby > > > > > > On Feb 21, 3:13 pm, JMcA <[EMAIL PROTECTED]> wrote: > > > > > > > Replying to myself, here. > > > > > > > Dan emailed me privately and suggested that I crossed the line with > > > > this last post (and perhaps some others) and came across as > > attacking > > > > people rather than ideas. For that, I absolutely apologize. > > > > > > > I definitely do not think that anyone involved here is stupid or > > close- > > > > minded (as Dan said that I came across as saying) and I sincerely > > > > apologize to anyone that I may have offended in this way. > > > > > > > I am still very disappointed that Google has decided to take this > > > > path, but that is their decision to make. I also think that it does > > > > fall afoul of the "Don't Be Evil" mantra, but reasonable people can > > > > disagree on that, and I don't believe its being done maliciously at > > > > all. > > > > > > > The ideas that I am suggesting here are pretty radical departures > > from > > > > the way typical network applications are developed and communicate > > on > > > > the Internet today. It can be very frustrating to have a vision of > > > > something really cool and powerful and not be able to get people to > > > > understand what it is that you see. > > > > > > > Dan, hackbod (and anyone else, for that matter): My apologies if I > > > > have offended. Alas, it does still seem to me that you all still > > > > don't really "get it." But I also still have respect for everyone > > who > > > > has participated and don't think any the less of anyone that may not > > > > share my vision for this. Hopefully continued work and adoption of > > > > XMPP in more sophisticated ways (for example, the way TiVO has > > started > > > > using it) will result in more people seeing the vision that I have > > and > > > > a greater understanding of the power and capabilities of the XMPP > > > > protocol and system. > > > > > > > Again, my sincere apologies to anyone I have offended. I won't say > > > > I'll completely drop the subject, but I do plan to take a deep > > breath > > > > and maybe walk away and make sure I have some perspective before > > > > responding to things in the future to keep from going overboard. > > > > -- > > > > Jeff > > > > > > > On Feb 19, 9:12 pm, JMcA <[EMAIL PROTECTED]> wrote: > > > > > > > > On Feb 19, 7:28 pm, hackbod <[EMAIL PROTECTED]> wrote: > > > > > > > > > One thing we seem to have not done a good job communicating is > > that > > > > > >XMPPis not, and has never been, a part of the Android platform. > > What > > > > > > we are talking about is a suite of Google value-added services > > that > > > > > > sit on top of the platform, which includes things like GTalk. > > > > > > > > /me bangs his head against the wall. > > > > > > > > I don't know about in general, but that has been made imminently > > clear > > > > > in this thread. > > > > > > > > And that's your first, and biggest, mistake. > > > > > > > > Please listen to what I'm saying, here. > > > > > > > > The XMPPService (or whatever it ends up being called) *should* be > > a > > > > > part of the core platform. It was short-sighted (though > > > > > understandably so) for it to be part of com.google.<whatever> It > > > > > should have been android.net.xmpp.*. What I'm trying to impress, > > > > > here, is how incredibly important this development is, and it > > seems > > > > > that you all can't see how important it is because its been > > developed > > > > > as part of the "value-added services". Thus my long message above > > > > > about how I was dumbfounded to see that Google had built this > > > > > incredibly powerful infrastructure (well, most of it, anyway), by > > > > > accident, and then didn't even *realize* it (and apparently still > > > > > don't). > > > > > > > > If you want to create a Google Talk specific IM client on android, > > I > > > > > agree completely that it should be in com.google.*, it could > > (probably > > > > > should) use the XMPPService (or whatever it ends up being called) > > that > > > > > would live probably in android.net.xmpp. > > > > > > > > > Providing a genericXMPPsolution at the platform level is > > extremely > > > > > > problematic at this point, because it would depend on servers > > running > > > > > > somewhere else that we would then be depending on at the > > platform > > > > > > level. That isn't to say that we would never have such a > > generic > > > > > > service, but it is not something we can do for 1.0 of the > > platform. > > > > > > > > But you have SMS/MMS support, which depends on huge amounts of > > > > > external infrastructure. You have http, which depends on > > literally > > > > > millions of pieces of infrastructure. You can defaultXMPPto use > > > > > Google Talk which *is* under Google's control (much more so than > > the > > > > > needed infrastructure for SMS!), but also allow an end-user to use > > > > > their ownXMPPserver which they can be responsible for. > > > > > > > > > For 1.0, the platform itself is only relying on standard > > services that > > > > > > are available on all phones (voice data, IP data, sms/mms, etc). > > > > > > > > And that is going to guarantee that android will not be anything > > more > > > > > than "just another phone". That development premise is *designed* > > to > > > > > prevent android from being something truly revolutionary. > > > > > > > > > The > > > > > > Google services that we are bundling with the platform make use > > of > > > > > > various non-standard services that are part of Google, and we > > have > > > > > > various APIs that let applications interact with those services. > > Even > > > > > > if we said that the GTalk protocol used there wasXMPP, I don't > > think > > > > > > it would give you any of the benefits you are asking for, > > because that > > > > > > would only be talking with the GoogleXMPPservers, since those > > are > > > > > > used for a number of other parts of the suite of Google services > > such > > > > > > as instigating syncs of the Contacts data. > > > > > > > > Good grief...try to think a bit outside of the box, here. > > > > > > > > TheXMPPservice doesn't *have* to only talk to the GoogleXMPP > > > > > servers. You open it up to allow people to put their > > ownXMPPservers > > > > > in there to talk to...maybe they lose the ability to use the > > google > > > > > specific value-added stuff in doing it...ok, that makes complete > > > > > sense, but to say that the XMPPService *necessarily* can only talk > > to > > > > > the Google Talk servers is disingenious. Charitably, I'll say > > that > > > > > apparently you haven't really thought this all the way through. > > > > > > > > Put the XMPPService in android.net.xmpp. If the jid configured in > > > > > that configuration screen happens to end in @gmail.com (or, > > presumably > > > > > a domain set up with Google Apps for Your Domain) then those > > value- > > > > > added google services magically start working. Hey, great, that's > > > > > really cool. > > > > > > > > All I'm really asking here is that you all give this idea a real, > > fair > > > > > shake. Toss the roadmap for 1.0 out for a minute, sit down, and > > > > > really consider what the possibilities are, here. Then, maybe > > > > > consider whether the roadmap needs to be revised a bit. Mindless > > > > > adherence to the roadmap without considering other developments is > > > > > every bit as dangerous to the success of a project as not having a > > > > > roadmap at all. > > > > > > > > Seriously folks, open your minds, sit down, and think about the > > > > > possibilities here. And please, in the mindset of "Don't Be > > Evil," > > > > > think about the possibilities beyond using them just with Google > > > > > branded services. > > > > > -- > > > > > Jeff- Hide quoted text - > > > > > > > - Show quoted text - > > > > > > > > -- BQ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] Announcing the new M5 SDK! http://android-developers.blogspot.com/2008/02/android-sdk-m5-rc14-now-available.html For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
