> 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 <bobbysoa...@gmail.com> 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 <jeff...@gmail.com> 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 <jeff...@gmail.com> wrote:

> > > > On Feb 19, 7:28 pm, hackbod <hack...@gmail.com> 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 -