> Lots of developers were excited about XMPP support in Android and were
> going crazy building peer to peer messaging services for Android. I
> personally was building a Twitter like service for Android. But with
> the latest announcement of plans with GTalk going native, many
> developers like me are forced to fallback on http, rest etc.,

> Let me explain how its affecting developers like us. Now instead of
> letting a free Jabber server doing the work for me, I'm forced to
> write my own REST server. Its not just a matter of falling back on
> alternate protocols but now we need to build the server components and
> all the mundane logic from scratch. Imagine for example building the
> twitter bot from scratch. Its a total waste of time and effort.

> People like me were attracted by the OpenSource ideology that Android
> stood for. Please do put XMPP support back on so we can continue
> building killer apps for Android. Trust in developers like us, We'll
> deliver.

> Thanks.

> Muthu Ramadoss
> intellibitz.com
> We develop open source solutions for mobile handsets, using Android.

>  Hi,

>  People like me were attracted by the OpenSource ideology that Android
>  stood for. Please do put XMPP support back on so we can continue
>  building killer apps for Android. Trust in developers like us, We'll
>  deliver.

> >  Hi,

> >  People like me were attracted by the OpenSource ideology that Android
> >  stood for. Please do put XMPP support back on so we can continue
> >  building killer apps for Android. Trust in developers like us, We'll
> >  deliver.

> Not the ideal solution, but is there something about the protocol that
> says the community can't
> develop its own implementation?

> Wink Saville

> I agree, but how likely is it that the community developed
> implementation would be included in the wide variety of handsets? I
> would say almost nil. The attraction of the XMPP stack before was that
> it would be there in the base android platform and available as a
> default for applications to make use of regardless of handset
> manufacturer.

> Mike

> Lots of developers were excited about XMPP support in Android and were
> going crazy building peer to peer messaging services for Android. I
> personally was building a Twitter like service for Android. But with
> the latest announcement of plans with GTalk going native, many
> developers like me are forced to fallback on http, rest etc.,

> Let me explain how its affecting developers like us. Now instead of
> letting a free Jabber server doing the work for me, I'm forced to
> write my own REST server. Its not just a matter of falling back on
> alternate protocols but now we need to build the server components and
> all the mundane logic from scratch. Imagine for example building the
> twitter bot from scratch. Its a total waste of time and effort.

> People like me were attracted by the OpenSource ideology that Android
> stood for. Please do put XMPP support back on so we can continue
> building killer apps for Android. Trust in developers like us, We'll
> deliver.

> Thanks.

> Muthu Ramadoss
> intellibitz.com
> We develop open source solutions for mobile handsets, using Android.

> Hi,

> Lots of developers were excited about XMPP support in Android and were
> going crazy building peer to peer messaging services for Android. I
> personally was building a Twitter like service for Android. But with
> the latest announcement of plans with GTalk going native, many
> developers like me are forced to fallback on http, rest etc.,

> Let me explain how its affecting developers like us. Now instead of
> letting a free Jabber server doing the work for me, I'm forced to
> write my own REST server. Its not just a matter of falling back on
> alternate protocols but now we need to build the server components and
> all the mundane logic from scratch. Imagine for example building the
> twitter bot from scratch. Its a total waste of time and effort.

> People like me were attracted by the OpenSource ideology that Android
> stood for. Please do put XMPP support back on so we can continue
> building killer apps for Android. Trust in developers like us, We'll
> deliver.

> Thanks.

> Muthu Ramadoss
> intellibitz.com
> We develop open source solutions for mobile handsets, using Android.

> > If I would like to create my own Jabber IM client, it would be weird
> > if I have to build it over API of another IM client (gtalk) - even if
> > "com.google.android.gtalkservice" would contain same classes as
> > "com.google.android.xmppService" did, it would still look weird.

> We are actually fairly careful about what is part of the generic
> platform, and what is not.  Specifically, things in the com.google.*
> namespaces are Google-specific APIs that are not part of the core
> platform: that is, you can create a device without any of the Google
> services in those namespaces and still have a working system.  This is
> why they are listed in the separate "Google APIs" part of the
> documentation.  Correspondingly, given a device that doesn't include
> the APIs, a third party can install on that device a separate .apk
> that provides the same features and works just like the one we are
> shipping with our platform.

> I can't address the specific situation of XMPP or GTalk, but I wanted
> to give an overview of where these fit in to the larger platform
> picture.  In general, I don't think these are APIs that we can provide
> as a standard part of the platform, since they rely on an external
> service that may not be available.  In this sense they are very
> different than SMS, which is a standard feature available to every
> phone.

> More discussion on the subject, and I have to say I agree with the
> comments there as well. XMPP inclusion was what excited me most about
> Android and this is a major let down...

> http://code.google.com/p/android/issues/detail?id=201

> Mike

> On Feb 15, 12:00 pm, hackbod <hack...@gmail.com> wrote:
> > On Feb 15, 10:19 am, fry <bender...@gmail.com> wrote:

> > > If I would like to create my own Jabber IM client, it would be weird
> > > if I have to build it over API of another IM client (gtalk) - even if
> > > "com.google.android.gtalkservice" would contain same classes as
> > > "com.google.android.xmppService" did, it would still look weird.

> > We are actually fairly careful about what is part of the generic
> > platform, and what is not.  Specifically, things in the com.google.*
> > namespaces are Google-specific APIs that are not part of the core
> > platform: that is, you can create a device without any of the Google
> > services in those namespaces and still have a working system.  This is
> > why they are listed in the separate "Google APIs" part of the
> > documentation.  Correspondingly, given a device that doesn't include
> > the APIs, a third party can install on that device a separate .apk
> > that provides the same features and works just like the one we are
> > shipping with our platform.

> > I can't address the specific situation of XMPP or GTalk, but I wanted
> > to give an overview of where these fit in to the larger platform
> > picture.  In general, I don't think these are APIs that we can provide
> > as a standard part of the platform, since they rely on an external
> > service that may not be available.  In this sense they are very
> > different than SMS, which is a standard feature available to every
> > phone.

> > We renamed the service because it is actually not compatible with XMPP,
> and
> > is currently hard-coded to Google's servers anyway.  It would be wrong
> for
> > us to call it "XMPPService" when it isn't really compatible with XMPP,
> so we
> > renamed it GTalkService to prevent confusion.

> Right...so its broken, and it needs to be fixed.  Moving away from a
> standards based protocol to something proprietary is a *really* bad
> idea.

> Maybe if you want to make an *additional* connection method that can
> work between android and gtalk available that supposedly will be more
> efficient, that might be a good idea.  But removing (or, I guess,
> moving away from) the ability to do standards compliant XMPP is the
> wrong direction.

> Tieing android to the gtalk server smacks of a walled garden
> attitude.  "Don't Be Evil" says that you should run, not walk, in the
> other direction.

> On Feb 15, 7:58 pm, "Dan Morrill" <morri...@google.com> wrote:
> > The XMPPService/GTalkService really only has 2 goals:

> Yes, and even the language used there indicates that this was a short-
> sighted way of going about it:

> "The XMPPServer/GTalkService really *ONLY* has 2 goals:"  (emphasis
> mine).

> Clearly you all didn't think this one through to think about how
> powerful full XMPP capabilities, down in the core of the system, can
> be.  This is an unusual situation, since Googlefolk are usually pretty
> well known for thinking through solution sets and how they can be more
> powerfully used and dramatically improve the state of the art.
> Unfortunately, you seem to have really dropped the ball on this one.

> > 1) provide a way to
> > efficiently send simple P2P-style messages (in the form of Intents)
> between
> > handsets, and 2) provide a way to send and receive IMs using Google's
> Talk
> > servers.  Originally, we intended this service only for our own use.
> > However we realized that #1 in particular would be very useful to all
> > developers, so we exposed the Service.  (Some developers might be
> interested
> > in #2 as well, although we don't think simply sending instant messages
> > through our servers is as exciting as the P2P functionality.)  The use
> of
> > XMPP under the covers was really just an implementation detail, and so
> you
> > might say it was a bad design decision to have named it XMPPService in
> the
> > first place.  Unfortunately it caused some confusion as to what the
> service
> > was intended for, which is why we've changed the name.

> Except that the use of XMPP is not an implementation detail.  Its a
> standards compliance issue, and its what really makes #1 and #2 so
> powerful.  By killing XMPP (I realize that it wasn't really XMPP to
> begin with, but that's a bug to be fixed, thus issue 201 in the
> android issue tracker...that really should be re-opened), you've
> killed most of the power of the service.

> > This is not a value judgment on XMPP.  XMPP supports a broad range of
> > functionality (such as federation) that are outside the scope of what we
> > intend the Service to be used for.

> Right, so you wanted to make it a walled garden.  Not good, guys.

> Remember, federation is all but completely invisible to the client,
> with a even halfway decent XMPP implementation for this (and you're
> building on Smack...most of the work is already done for you), the
> federation, and thus the further elimination of walled gardens comes
> along basically for free.

> If XMPP isn't efficient enough for mobile uses (which I'm most
> certainly not convinced that claim is at all true), then consider
> adding an additional connection methed for the gtalk service from
> android...then you can sell the gtalk service as being more efficient
> (maybe), and that's fine, but sacrificing the openness of the platform
> on the alter of "mobile efficiency" should be embarrassing to you.

> > Earlier I suggested that developers who want full standards-compliant
> XMPP
> > access should use a third-party XMPP library in their applications.
> > However, Davanum Srinivas suggested instead that interested developers
> > create a reusable XMPP Service that has full support for the protocol.
>  I
> > have to agree that that's a much better idea than mine!

> Yes, creation of a reusable XMPP Service with full support for the
> protocol is a great idea.  But why Google is doing 95% (that's a WAG
> number) of the work and then flushing it down the toilet is totally
> beyond me.

> Google really needs to rethink this.  Its a *really* bad idea.

> --
> Jeff

> It looks like you've misunderstood one of the key issues.  There has been no
> change to the "core" of Android at all.

> As Dianne also mentioned elsewhere in this thread, neither the old nor new
> services are part of the set of libraries for Android.  They are both in a
> com.google.* package, and as such are part of the optional Google APIs that
> may not be present on all Android devices.  Please check out this page in
> the documentation for more details:http://code.google.com/android/toolbox/google-apis.html

> In other words, neither the old nor new services are part of Android; they
> are part of Google's application software suite that we are creating for
> Android.  We are exposing the functionality of the GTalkService as a
> courtesy to other developers, because it seems generally useful.  However,
> since the service is a third-party library provided by Google and tied to
> Google's Talk servers, we're optimizing that software to work well with our
> servers.

> Best,

> - Dan

> On Sat, Feb 16, 2008 at 9:07 AM, JMcA <jeff...@gmail.com> wrote:

> > > We renamed the service because it is actually not compatible with XMPP,
> > and
> > > is currently hard-coded to Google's servers anyway.  It would be wrong
> > for
> > > us to call it "XMPPService" when it isn't really compatible with XMPP,
> > so we
> > > renamed it GTalkService to prevent confusion.

> > Right...so its broken, and it needs to be fixed.  Moving away from a
> > standards based protocol to something proprietary is a *really* bad
> > idea.

> > Maybe if you want to make an *additional* connection method that can
> > work between android and gtalk available that supposedly will be more
> > efficient, that might be a good idea.  But removing (or, I guess,
> > moving away from) the ability to do standards compliant XMPP is the
> > wrong direction.

> > Tieing android to the gtalk server smacks of a walled garden
> > attitude.  "Don't Be Evil" says that you should run, not walk, in the
> > other direction.

> > On Feb 15, 7:58 pm, "Dan Morrill" <morri...@google.com> wrote:
> > > The XMPPService/GTalkService really only has 2 goals:

> > Yes, and even the language used there indicates that this was a short-
> > sighted way of going about it:

> > "The XMPPServer/GTalkService really *ONLY* has 2 goals:"  (emphasis
> > mine).

> > Clearly you all didn't think this one through to think about how
> > powerful full XMPP capabilities, down in the core of the system, can
> > be.  This is an unusual situation, since Googlefolk are usually pretty
> > well known for thinking through solution sets and how they can be more
> > powerfully used and dramatically improve the state of the art.
> > Unfortunately, you seem to have really dropped the ball on this one.

> > > 1) provide a way to
> > > efficiently send simple P2P-style messages (in the form of Intents)
> > between
> > > handsets, and 2) provide a way to send and receive IMs using Google's
> > Talk
> > > servers.  Originally, we intended this service only for our own use.
> > > However we realized that #1 in particular would be very useful to all
> > > developers, so we exposed the Service.  (Some developers might be
> > interested
> > > in #2 as well, although we don't think simply sending instant messages
> > > through our servers is as exciting as the P2P functionality.)  The use
> > of
> > > XMPP under the covers was really just an implementation detail, and so
> > you
> > > might say it was a bad design decision to have named it XMPPService in
> > the
> > > first place.  Unfortunately it caused some confusion as to what the
> > service
> > > was intended for, which is why we've changed the name.

> > Except that the use of XMPP is not an implementation detail.  Its a
> > standards compliance issue, and its what really makes #1 and #2 so
> > powerful.  By killing XMPP (I realize that it wasn't really XMPP to
> > begin with, but that's a bug to be fixed, thus issue 201 in the
> > android issue tracker...that really should be re-opened), you've
> > killed most of the power of the service.

> > > This is not a value judgment on XMPP.  XMPP supports a broad range of
> > > functionality (such as federation) that are outside the scope of what we
> > > intend the Service to be used for.

> > Right, so you wanted to make it a walled garden.  Not good, guys.

> > Remember, federation is all but completely invisible to the client,
> > with a even halfway decent XMPP implementation for this (and you're
> > building on Smack...most of the work is already done for you), the
> > federation, and thus the further elimination of walled gardens comes
> > along basically for free.

> > If XMPP isn't efficient enough for mobile uses (which I'm most
> > certainly not convinced that claim is at all true), then consider
> > adding an additional connection methed for the gtalk service from
> > android...then you can sell the gtalk service as being more efficient
> > (maybe), and that's fine, but sacrificing the openness of the platform
> > on the alter of "mobile efficiency" should be embarrassing to you.

> > > Earlier I suggested that developers who want full standards-compliant
> > XMPP
> > > access should use a third-party XMPP library in their applications.
> > > However, Davanum Srinivas suggested instead that interested developers
> > > create a reusable XMPP Service that has full support for the protocol.
> >  I
> > > have to agree that that's a much better idea than mine!

> > Yes, creation of a reusable XMPP Service with full support for the
> > protocol is a great idea.  But why Google is doing 95% (that's a WAG
> > number) of the work and then flushing it down the toilet is totally
> > beyond me.

> > Google really needs to rethink this.  Its a *really* bad idea.

> > --
> > Jeff

> Yeah, ok, so I caught a hint of that earlier.

> And that's even more disappointing.

> Particularly seeing as how its basically a cop out of doing the right
> thing here.

> On Feb 16, 3:06 pm, "Dan Morrill" <morri...@google.com> wrote:
> > Hi, Jeff!

> > It looks like you've misunderstood one of the key issues.  There has
> been no
> > change to the "core" of Android at all.

> > As Dianne also mentioned elsewhere in this thread, neither the old nor
> new
> > services are part of the set of libraries for Android.  They are both in
> a
> > com.google.* package, and as such are part of the optional Google APIs
> that
> > may not be present on all Android devices.  Please check out this page
> in
> > the documentation for more details:
> http://code.google.com/android/toolbox/google-apis.html

> > In other words, neither the old nor new services are part of Android;
> they
> > are part of Google's application software suite that we are creating for
> > Android.  We are exposing the functionality of the GTalkService as a
> > courtesy to other developers, because it seems generally useful.
>  However,
> > since the service is a third-party library provided by Google and tied
> to
> > Google's Talk servers, we're optimizing that software to work well with
> our
> > servers.

> > Best,

> > - Dan

> > On Sat, Feb 16, 2008 at 9:07 AM, JMcA <jeff...@gmail.com> wrote:

> > > > We renamed the service because it is actually not compatible with
> XMPP,
> > > and
> > > > is currently hard-coded to Google's servers anyway.  It would be
> wrong
> > > for
> > > > us to call it "XMPPService" when it isn't really compatible with
> XMPP,
> > > so we
> > > > renamed it GTalkService to prevent confusion.

> > > Right...so its broken, and it needs to be fixed.  Moving away from a
> > > standards based protocol to something proprietary is a *really* bad
> > > idea.

> > > Maybe if you want to make an *additional* connection method that can
> > > work between android and gtalk available that supposedly will be more
> > > efficient, that might be a good idea.  But removing (or, I guess,
> > > moving away from) the ability to do standards compliant XMPP is the
> > > wrong direction.

> > > Tieing android to the gtalk server smacks of a walled garden
> > > attitude.  "Don't Be Evil" says that you should run, not walk, in the
> > > other direction.

> > > On Feb 15, 7:58 pm, "Dan Morrill" <morri...@google.com> wrote:
> > > > The XMPPService/GTalkService really only has 2 goals:

> > > Yes, and even the language used there indicates that this was a short-
> > > sighted way of going about it:

> > > "The XMPPServer/GTalkService really *ONLY* has 2 goals:"  (emphasis
> > > mine).

> > > Clearly you all didn't think this one through to think about how
> > > powerful full XMPP capabilities, down in the core of the system, can
> > > be.  This is an unusual situation, since Googlefolk are usually pretty
> > > well known for thinking through solution sets and how they can be more
> > > powerfully used and dramatically improve the state of the art.
> > > Unfortunately, you seem to have really dropped the ball on this one.

> > > > 1) provide a way to
> > > > efficiently send simple P2P-style messages (in the form of Intents)
> > > between
> > > > handsets, and 2) provide a way to send and receive IMs using
> Google's
> > > Talk
> > > > servers.  Originally, we intended this service only for our own use.
> > > > However we realized that #1 in particular would be very useful to
> all
> > > > developers, so we exposed the Service.  (Some developers might be
> > > interested
> > > > in #2 as well, although we don't think simply sending instant
> messages
> > > > through our servers is as exciting as the P2P functionality.)  The
> use
> > > of
> > > > XMPP under the covers was really just an implementation detail, and
> so
> > > you
> > > > might say it was a bad design decision to have named it XMPPService
> in
> > > the
> > > > first place.  Unfortunately it caused some confusion as to what the
> > > service
> > > > was intended for, which is why we've changed the name.

> > > Except that the use of XMPP is not an implementation detail.  Its a
> > > standards compliance issue, and its what really makes #1 and #2 so
> > > powerful.  By killing XMPP (I realize that it wasn't really XMPP to
> > > begin with, but that's a bug to be fixed, thus issue 201 in the
> > > android issue tracker...that really should be re-opened), you've
> > > killed most of the power of the service.

> > > > This is not a value judgment on XMPP.  XMPP supports a broad range
> of
> > > > functionality (such as federation) that are outside the scope of
> what we
> > > > intend the Service to be used for.

> > > Right, so you wanted to make it a walled garden.  Not good, guys.

> > > Remember, federation is all but completely invisible to the client,
> > > with a even halfway decent XMPP implementation for this (and you're
> > > building on Smack...most of the work is already done for you), the
> > > federation, and thus the further elimination of walled gardens comes
> > > along basically for free.

> > > If XMPP isn't efficient enough for mobile uses (which I'm most
> > > certainly not convinced that claim is at all true), then consider
> > > adding an additional connection methed for the gtalk service from
> > > android...then you can sell the gtalk service as being more efficient
> > > (maybe), and that's fine, but sacrificing the openness of the platform
> > > on the alter of "mobile efficiency" should be embarrassing to you.

> > > > Earlier I suggested that developers who want full
> standards-compliant
> > > XMPP
> > > > access should use a third-party XMPP library in their applications.
> > > > However, Davanum Srinivas suggested instead that interested
> developers
> > > > create a reusable XMPP Service that has full support for the
> protocol.
> > >  I
> > > > have to agree that that's a much better idea than mine!

> > > Yes, creation of a reusable XMPP Service with full support for the
> > > protocol is a great idea.  But why Google is doing 95% (that's a WAG
> > > number) of the work and then flushing it down the toilet is totally
> > > beyond me.

> > > Google really needs to rethink this.  Its a *really* bad idea.

> > > --
> > > Jeff

> While we would love to support each person's favorite protocol and library
> in the Android core, we have to make tradeoffs about what to include and
> what not to include.  Unfortunately an XMPP service is not on the feature
> list for Android 1.0.

> I'm sorry to hear that Google's third-party GTalkService doesn't meet your
> needs.  Since this is clearly an "itch" (as they say) for you, I encourage
> you to create your own XMPP Service, and look forward to using it myself one
> day.

> - Dan

> On Sat, Feb 16, 2008 at 1:41 PM, JMcA <jeff...@gmail.com> wrote:

> > Yeah, ok, so I caught a hint of that earlier.

> > And that's even more disappointing.

> > Particularly seeing as how its basically a cop out of doing the right
> > thing here.

> > On Feb 16, 3:06 pm, "Dan Morrill" <morri...@google.com> wrote:
> > > Hi, Jeff!

> > > It looks like you've misunderstood one of the key issues.  There has
> > been no
> > > change to the "core" of Android at all.

> > > As Dianne also mentioned elsewhere in this thread, neither the old nor
> > new
> > > services are part of the set of libraries for Android.  They are both in
> > a
> > > com.google.* package, and as such are part of the optional Google APIs
> > that
> > > may not be present on all Android devices.  Please check out this page
> > in
> > > the documentation for more details:
> >http://code.google.com/android/toolbox/google-apis.html

> > > In other words, neither the old nor new services are part of Android;
> > they
> > > are part of Google's application software suite that we are creating for
> > > Android.  We are exposing the functionality of the GTalkService as a
> > > courtesy to other developers, because it seems generally useful.
> >  However,
> > > since the service is a third-party library provided by Google and tied
> > to
> > > Google's Talk servers, we're optimizing that software to work well with
> > our
> > > servers.

> > > Best,

> > > - Dan

> > > On Sat, Feb 16, 2008 at 9:07 AM, JMcA <jeff...@gmail.com> wrote:

> > > > > We renamed the service because it is actually not compatible with
> > XMPP,
> > > > and
> > > > > is currently hard-coded to Google's servers anyway.  It would be
> > wrong
> > > > for
> > > > > us to call it "XMPPService" when it isn't really compatible with
> > XMPP,
> > > > so we
> > > > > renamed it GTalkService to prevent confusion.

> > > > Right...so its broken, and it needs to be fixed.  Moving away from a
> > > > standards based protocol to something proprietary is a *really* bad
> > > > idea.

> > > > Maybe if you want to make an *additional* connection method that can
> > > > work between android and gtalk available that supposedly will be more
> > > > efficient, that might be a good idea.  But removing (or, I guess,
> > > > moving away from) the ability to do standards compliant XMPP is the
> > > > wrong direction.

> > > > Tieing android to the gtalk server smacks of a walled garden
> > > > attitude.  "Don't Be Evil" says that you should run, not walk, in the
> > > > other direction.

> > > > On Feb 15, 7:58 pm, "Dan Morrill" <morri...@google.com> wrote:
> > > > > The XMPPService/GTalkService really only has 2 goals:

> > > > Yes, and even the language used there indicates that this was a short-
> > > > sighted way of going about it:

> > > > "The XMPPServer/GTalkService really *ONLY* has 2 goals:"  (emphasis
> > > > mine).

> > > > Clearly you all didn't think this one through to think about how
> > > > powerful full XMPP capabilities, down in the core of the system, can
> > > > be.  This is an unusual situation, since Googlefolk are usually pretty
> > > > well known for thinking through solution sets and how they can be more
> > > > powerfully used and dramatically improve the state of the art.
> > > > Unfortunately, you seem to have really dropped the ball on this one.

> > > > > 1) provide a way to
> > > > > efficiently send simple P2P-style messages (in the form of Intents)
> > > > between
> > > > > handsets, and 2) provide a way to send and receive IMs using
> > Google's
> > > > Talk
> > > > > servers.  Originally, we intended this service only for our own use.
> > > > > However we realized that #1 in particular would be very useful to
> > all
> > > > > developers, so we exposed the Service.  (Some developers might be
> > > > interested
> > > > > in #2 as well, although we don't think simply sending instant
> > messages
> > > > > through our servers is as exciting as the P2P functionality.)  The
> > use
> > > > of
> > > > > XMPP under the covers was really just an implementation detail, and
> > so
> > > > you
> > > > > might say it was a bad design decision to have named it XMPPService
> > in
> > > > the
> > > > > first place.  Unfortunately it caused some confusion as to what the
> > > > service
> > > > > was intended for, which is why we've changed the name.

> > > > Except that the use of XMPP is not an implementation detail.  Its a
> > > > standards compliance issue, and its what really makes #1 and #2 so
> > > > powerful.  By killing XMPP (I realize that it wasn't really XMPP to
> > > > begin with, but that's a bug to be fixed, thus issue 201 in the
> > > > android issue tracker...that really should be re-opened), you've
> > > > killed most of the power of the service.

> > > > > This is not a value judgment on XMPP.  XMPP supports a broad range
> > of
> > > > > functionality (such as federation) that are outside the scope of
> > what we
> > > > > intend the Service to be used for.

> > > > Right, so you wanted to make it a walled garden.  Not good, guys.

> > > > Remember, federation is all but completely invisible to the client,
> > > > with a even halfway decent XMPP implementation for this (and you're
> > > > building on Smack...most of the work is already done for you), the
> > > > federation, and thus the further elimination of walled gardens comes
> > > > along basically for free.

> > > > If XMPP isn't efficient enough for mobile uses (which I'm most
> > > > certainly not convinced that claim is at all true), then consider
> > > > adding an additional connection methed for the gtalk service from
> > > > android...then you can sell the gtalk service as being more efficient
> > > > (maybe), and that's fine, but sacrificing the openness of the platform
> > > > on the alter of "mobile efficiency" should be embarrassing to you.

> > > > > Earlier I suggested that developers who want full
> > standards-compliant
> > > > XMPP
> > > > > access should use a third-party XMPP library in their applications.
> > > > > However, Davanum Srinivas suggested instead that interested
> > developers
> > > > > create a reusable XMPP Service that has full support for the
> > protocol.
> > > >  I
> > > > > have to agree that that's a much better idea than mine!

> > > > Yes, creation of a reusable XMPP Service with full support for the
> > > > protocol is a great idea.  But why Google is doing 95% (that's a WAG
> > > > number) of the work and then flushing it down the toilet is totally
> > > > beyond me.

> > > > Google really needs to rethink this.  Its a *really* bad idea.

> > > > --
> > > > Jeff

> All well and good and reasonable sounding, but seriously...go search
> the webternets.  *NOONE* other than googlefolk think that this
> direction is a good idea.  The most charitable response I've found to
> this statement of direction was someone who said that they weren't
> familiar with XMPP enough to really comment on it but that he
> suspected Google would get a major backlash on it...and he was right.

> You have a long beta period to get lots of feedback and make the
> product the best product possible.  Well, you're getting feedback in
> spades, here.  Pay attention to it rather than blowing it off with
> simplistic platitudes please.

> Go look at the comments on issue 201 in the issue tracker.  You've got
> people commenting that the XMPP capabilities are the only real
> distinguishing feature that are pulling them to work with Android.  A
> low level XMPP service is really the only feature that significantly
> distinguishes Android from any other handset OS.

> Go look at the blog postings, (you've got a great search engine to go
> find them), *everyone* that has commented about this issue is
> absolutely dumbfounded that you all have made this decision.

> What does it take to get Google to go back and consider this issue
> again?  Because you all have made a really bad decision on this one.

> Alas, I'm really not a programmer, so writing my own XMPPService is
> not really in the cards, but I'm very interested in using Android with
> a good core XMPPService...without it, meh, its gonna be "Just Another
> Phone".  Big deal.

> On Feb 16, 5:53 pm, "Dan Morrill" <morri...@google.com> wrote:
> > Hi again, Jeff!

> > While we would love to support each person's favorite protocol and
> library
> > in the Android core, we have to make tradeoffs about what to include and
> > what not to include.  Unfortunately an XMPP service is not on the
> feature
> > list for Android 1.0.

> > I'm sorry to hear that Google's third-party GTalkService doesn't meet
> your
> > needs.  Since this is clearly an "itch" (as they say) for you, I
> encourage
> > you to create your own XMPP Service, and look forward to using it myself
> one
> > day.

> > - Dan

> > On Sat, Feb 16, 2008 at 1:41 PM, JMcA <jeff...@gmail.com> wrote:

> > > Yeah, ok, so I caught a hint of that earlier.

> > > And that's even more disappointing.

> > > Particularly seeing as how its basically a cop out of doing the right
> > > thing here.

> > > On Feb 16, 3:06 pm, "Dan Morrill" <morri...@google.com> wrote:
> > > > Hi, Jeff!

> > > > It looks like you've misunderstood one of the key issues.  There has
> > > been no
> > > > change to the "core" of Android at all.

> > > > As Dianne also mentioned elsewhere in this thread, neither the old
> nor
> > > new
> > > > services are part of the set of libraries for Android.  They are
> both in
> > > a
> > > > com.google.* package, and as such are part of the optional Google
> APIs
> > > that
> > > > may not be present on all Android devices.  Please check out this
> page
> > > in
> > > > the documentation for more details:
> > >http://code.google.com/android/toolbox/google-apis.html

> > > > In other words, neither the old nor new services are part of
> Android;
> > > they
> > > > are part of Google's application software suite that we are creating
> for
> > > > Android.  We are exposing the functionality of the GTalkService as a
> > > > courtesy to other developers, because it seems generally useful.
> > >  However,
> > > > since the service is a third-party library provided by Google and
> tied
> > > to
> > > > Google's Talk servers, we're optimizing that software to work well
> with
> > > our
> > > > servers.

> > > > Best,

> > > > - Dan

> > > > On Sat, Feb 16, 2008 at 9:07 AM, JMcA <jeff...@gmail.com> wrote:

> > > > > > We renamed the service because it is actually not compatible
> with
> > > XMPP,
> > > > > and
> > > > > > is currently hard-coded to Google's servers anyway.  It would be
> > > wrong
> > > > > for
> > > > > > us to call it "XMPPService" when it isn't really compatible with
> > > XMPP,
> > > > > so we
> > > > > > renamed it GTalkService to prevent confusion.

> > > > > Right...so its broken, and it needs to be fixed.  Moving away from
> a
> > > > > standards based protocol to something proprietary is a *really*
> bad
> > > > > idea.

> > > > > Maybe if you want to make an *additional* connection method that
> can
> > > > > work between android and gtalk available that supposedly will be
> more
> > > > > efficient, that might be a good idea.  But removing (or, I guess,
> > > > > moving away from) the ability to do standards compliant XMPP is
> the
> > > > > wrong direction.

> > > > > Tieing android to the gtalk server smacks of a walled garden
> > > > > attitude.  "Don't Be Evil" says that you should run, not walk, in
> the
> > > > > other direction.

> > > > > On Feb 15, 7:58 pm, "Dan Morrill" <morri...@google.com> wrote:
> > > > > > The XMPPService/GTalkService really only has 2 goals:

> > > > > Yes, and even the language used there indicates that this was a
> short-
> > > > > sighted way of going about it:

> > > > > "The XMPPServer/GTalkService really *ONLY* has 2
> goals:"  (emphasis
> > > > > mine).

> > > > > Clearly you all didn't think this one through to think about how
> > > > > powerful full XMPP capabilities, down in the core of the system,
> can
> > > > > be.  This is an unusual situation, since Googlefolk are usually
> pretty
> > > > > well known for thinking through solution sets and how they can be
> more
> > > > > powerfully used and dramatically improve the state of the art.
> > > > > Unfortunately, you seem to have really dropped the ball on this
> one.

> > > > > > 1) provide a way to
> > > > > > efficiently send simple P2P-style messages (in the form of
> Intents)
> > > > > between
> > > > > > handsets, and 2) provide a way to send and receive IMs using
> > > Google's
> > > > > Talk
> > > > > > servers.  Originally, we intended this service only for our own
> use.
> > > > > > However we realized that #1 in particular would be very useful
> to
> > > all
> > > > > > developers, so we exposed the Service.  (Some developers might
> be
> > > > > interested
> > > > > > in #2 as well, although we don't think simply sending instant
> > > messages
> > > > > > through our servers is as exciting as the P2P
> functionality.)  The
> > > use
> > > > > of
> > > > > > XMPP under the covers was really just an implementation detail,
> and
> > > so
> > > > > you
> > > > > > might say it was a bad design decision to have named it
> XMPPService
> > > in
> > > > > the
> > > > > > first place.  Unfortunately it caused some confusion as to what
> the
> > > > > service
> > > > > > was intended for, which is why we've changed the name.

> > > > > Except that the use of XMPP is not an implementation detail.  Its
> a
> > > > > standards compliance issue, and its what really makes #1 and #2 so
> > > > > powerful.  By killing XMPP (I realize that it wasn't really XMPP
> to
> > > > > begin with, but that's a bug to be fixed, thus issue 201 in the
> > > > > android issue tracker...that really should be re-opened), you've
> > > > > killed most of the power of the service.

> > > > > > This is not a value judgment on XMPP.  XMPP supports a broad
> range
> > > of
> > > > > > functionality (such as federation) that are outside the scope of
> > > what we
> > > > > > intend the Service to be used for.

> > > > > Right, so you wanted to make it a walled garden.  Not good, guys.

> > > > > Remember, federation is all but completely invisible to the
> client,
> > > > > with a even halfway decent XMPP implementation for this (and
> you're
> > > > > building on Smack...most of the work is already done for you), the
> > > > > federation, and thus the further elimination of walled gardens
> comes
> > > > > along basically for free.

> > > > > If XMPP isn't efficient enough for mobile uses (which I'm most
> > > > > certainly not convinced that claim is at all true), then consider
> > > > > adding an additional connection methed for the gtalk service from
> > > > > android...then you can sell the gtalk service as being more
> efficient
> > > > > (maybe), and that's fine, but sacrificing the openness of the
> platform
> > > > > on the alter of "mobile efficiency" should be embarrassing to you.

> > > > > > Earlier I suggested that developers who want full
> > > standards-compliant
> > > > > XMPP
> > > > > > access should use a third-party XMPP library in their
> applications.
> > > > > > However, Davanum Srinivas suggested instead that interested
> > > developers
> > > > > > create a reusable XMPP Service that has full support for the
> > > protocol.
> > > > >  I
> > > > > > have to agree that that's a much better idea than mine!

> > > > > Yes, creation of a reusable XMPP Service

> It looks like you've misunderstood one of the key issues.  There has been no
> change to the "core" of Android at all.

> As Dianne also mentioned elsewhere in this thread, neither the old nor new
> services are part of the set of libraries for Android.  They are both in a
> com.google.* package, and as such are part of the optional Google APIs that
> may not be present on all Android devices.  Please check out this page in
> the documentation for more details:http://code.google.com/android/toolbox/google-apis.html

> In other words, neither the old nor new services are part of Android; they
> are part of Google's application software suite that we are creating for
> Android.  We are exposing the functionality of the GTalkService as a
> courtesy to other developers, because it seems generally useful.  However,
> since the service is a third-party library provided by Google and tied to
> Google's Talk servers, we're optimizing that software to work well with our
> servers.

> Best,

> - Dan

> On Sat, Feb 16, 2008 at 9:07 AM, JMcA <jeff...@gmail.com> wrote:

> > > We renamed the service because it is actually not compatible with XMPP,
> > and
> > > is currently hard-coded to Google's servers anyway.  It would be wrong
> > for
> > > us to call it "XMPPService" when it isn't really compatible with XMPP,
> > so we
> > > renamed it GTalkService to prevent confusion.

> > Right...so its broken, and it needs to be fixed.  Moving away from a
> > standards based protocol to something proprietary is a *really* bad
> > idea.

> > Maybe if you want to make an *additional* connection method that can
> > work between android and gtalk available that supposedly will be more
> > efficient, that might be a good idea.  But removing (or, I guess,
> > moving away from) the ability to do standards compliant XMPP is the
> > wrong direction.

> > Tieing android to the gtalk server smacks of a walled garden
> > attitude.  "Don't Be Evil" says that you should run, not walk, in the
> > other direction.

> > On Feb 15, 7:58 pm, "Dan Morrill" <morri...@google.com> wrote:
> > > The XMPPService/GTalkService really only has 2 goals:

> > Yes, and even the language used there indicates that this was a short-
> > sighted way of going about it:

> > "The XMPPServer/GTalkService really *ONLY* has 2 goals:"  (emphasis
> > mine).

> > Clearly you all didn't think this one through to think about how
> > powerful full XMPP capabilities, down in the core of the system, can
> > be.  This is an unusual situation, since Googlefolk are usually pretty
> > well known for thinking through solution sets and how they can be more
> > powerfully used and dramatically improve the state of the art.
> > Unfortunately, you seem to have really dropped the ball on this one.

> > > 1) provide a way to
> > > efficiently send simple P2P-style messages (in the form of Intents)
> > between
> > > handsets, and 2) provide a way to send and receive IMs using Google's
> > Talk
> > > servers.  Originally, we intended this service only for our own use.
> > > However we realized that #1 in particular would be very useful to all
> > > developers, so we exposed the Service.  (Some developers might be
> > interested
> > > in #2 as well, although we don't think simply sending instant messages
> > > through our servers is as exciting as the P2P functionality.)  The use
> > of
> > > XMPP under the covers was really just an implementation detail, and so
> > you
> > > might say it was a bad design decision to have named it XMPPService in
> > the
> > > first place.  Unfortunately it caused

> So, I've been saying for...I don't know, 3 years or more maybe?...that
> XMPP had the potential to really become the "Next Great Thing" on the
> Internet.  And I've been doing system and network administration long
> enough to remember when the "Next Great Thing" was HTTP/HTML, ok?  I'm
> talking this sort of level of importance.

> Let me explain what I mean by that.  XMPP, obviously, is a fantastic
> technology to build an IM and presense system on, and that has worked
> very well, and that overall system continues to grow and gain more
> users.  But XMPP is far, far more capable than just that.  For these 3
> years or so, I've been advocating to anyone that would listen that
> XMPP has the potential to be the next big data transport system for
> the Internet.  The properties are fantastic for it, if people would
> just realize it and start to make use of it.  Alas, again, I'm not
> much of a programmer, so I didn't have the skills to develop things
> that would show this off particularly well.

> At the risk of buzzword overload, XMPP is (or at least can be) a
> network-transparent, Internet-scale, platform-neutral, *2-way* (that's
> important since HTTP basically isn't), secure, reliable, and easy to
> use IPC and general app communications layer.  The way the current
> HTTP based systems work, large services that want to build slick
> interactive applications have to build out large web farms to handle
> the polling required by techniques like AJAX.  XMPP is much cleaner
> because it doesn't require polling (although the paradigm can be used
> within XMPP if the developer wants), thus the scaling demands are much
> smaller.

> Anyway, there are people starting to talk about how XMPP can do all of
> this, now...again, you can search the webternets and find them (some
> of the guys over at Jive Software have been some of the more active
> people talking about all this)...and I've been saying this was
> possible for years, like I said.

> So, imagine my surprise when I finally take the time to download the
> Android SDK and emulator, fire it up, start poking at it and playing
> with it and reading about it and Lo and Behold!  Google has gone and
> *done* it.  Google has built a system (well, mostly, the XMPPService
> still needed a little work, but the basics were there) that allows
> easy agent-level communications between software components in a
> network transparent and platform neutral way.

> Then, imagine my disappointment when, five days later, the new SDK is
> released and Google has done a s/XMPP/GTalk/, and then I go and read
> the explanation and a couple of things become apparent:

> 1) This potentially world changing (well, the computing world, anyway)
> capability came to be basically by *accident*.  Well, ok, there's a
> long history of inventions, and discoveries happening by accident
> (penicillin, vulcanized rubber, X-rays...there's plenty more where
> that came from)
> 2) *They apparently don't even realize what it is that they've got!*
> and
> 3) the planned roadmap is gonna absolutely cripple this by playing
> walled garden games with it.  Apparently, because of #2, since the
> googlefolk don't realize the importance of what it is that they've
> developed here, they're not considering how important this is to be
> treated with respect, and they're about to wall it off into a walled
> garden, not realizing the damage that they're going to do in the
> process.  Ok, maybe Google's walls for their walled garden are lower
> than typical walled gardens, but its still a walled garden and walled
> gardens are evil.

> There's a lot of really cool stuff in Android.  Its pretty slick, lots
> of eye candy, the Intent and IntentReceiver stuff looks like a pretty
> slick programming paradigm (again, I'm not really a programmer so I'm
> not the best judge of that).  Overall its quite cool, but none of that
> stuff is really revolutionary.  Its all just evolutionary...a big jump
> in evolution, to be sure, but still just evolutionary.

> But XMPP as a core system service that can be used as an IPC system++,
> now *THAT* could possibly change the computing world.  And you all are
> getting ready to trash it with your further roadmap, because *NOTHING*
> will kill this possibility faster than playing walled garden games
> with it, and make no bones about it, you can talk all you want about
> making things more efficient, and mobile phone cpu and battery and
> rationalize it all you want, and your rationalizations may even be
> based on real issues (though I think XMPP can be considerably more
> efficient than you give it credit), but you're still building a walled
> garden.

> Oh, and one more point, you'll notice that I basically haven't said
> anything about this being about mobile phones.  That's very
> intentional.  This isn't just about mobile phones.  Though Android is
> designed for mobile phone use, of course, and its interesting that
> this is first developing in a product designed for mobile phones,
> which is about the last place I expected it, but this possible
> revolution is about *all* of computing.

> So, people are creating apps that pass Intents around, and we're
> starting to see people playing with sending Intents from one Android
> to another.  But think about the possibilities of sending Intents from
> your Android handset to your KDE desktop (or Gnome, or Windows, or Mac
> OS X...I said KDE to start with because that's what I personally use
> for my desktop), or maybe sending Intents from your Android handset to
> your company's groupware server, or collaboration server, or custom
> written apps in an app server (JBoss, Glassfish, whatever offering MS
> has in this space, and the like).

> The possibilities here are endless, and the implications go far beyond
> just how competitive the mobile phone handset market is.

> Take it out of the com.google namespace, this needs to be core to
> Android (android.net.xmpp ?), this is the single most important
> feature that Android has to offer the world, please don't kill it
> because you don't realize the possibilities of it.

> I know a lot of this sounds melodramatic and full of hyperbole.  Its
> not.  Take a step back and think about what you're doing, here.

> On Feb 16, 3:06 pm, "Dan Morrill" <morri...@google.com> wrote:

> > Hi, Jeff!

> > It looks like you've misunderstood one of the key issues.  There has been no
> > change to the "core" of Android at all.

> > As Dianne also mentioned elsewhere in this thread, neither the old nor new
> > services are part of the set of libraries for Android.  They are both in a
> > com.google.* package, and as such are part of the optional Google APIs that
> > may not be present on all Android devices.  Please check out this page in
> > the documentation for more details:http://code.google.com/android/toolbox/google-apis.html

> > In other words, neither the old nor new services are part of Android; they
> > are part of Google's application software suite that we are creating for
> > Android.  We are exposing the functionality of the GTalkService as a
> > courtesy to other developers, because it seems generally useful.  However,
> > since the service is a third-party library provided by Google and tied to
> > Google's Talk servers, we're optimizing that software to work well with our
> > servers.

> > Best,

> > - Dan

> > On Sat, Feb 16, 2008 at 9:07 AM, JMcA <jeff...@gmail.com> wrote:

> > > > We renamed the service because it is actually not compatible with XMPP,
> > > and
> > > > is currently hard-coded to Google's servers anyway.  It would be wrong
> > > for
> > > > us to call it "XMPPService" when it isn't really compatible with XMPP,
> > > so we
> > > > renamed it GTalkService to prevent confusion.

> > > Right...so its broken, and it needs to be fixed.  Moving away from a
> > > standards based protocol to something proprietary is a *really* bad
> > > idea.

> > > Maybe if you want to make an *additional* connection method that can
> > > work between android and gtalk available that supposedly will be more
> > > efficient, that might be a good idea.  But removing (or, I guess,
> > > moving away from) the ability to do standards compliant XMPP is the
> > > wrong direction.

> > > Tieing android to the gtalk server smacks of a walled garden
> > > attitude.  "Don't Be Evil" says that you should run, not walk, in the
> > > other direction.

> > > On Feb 15, 7:58 pm, "Dan Morrill" <morri...@google.com> wrote:
> > > > The XMPPService/GTalkService really only has 2 goals:

> > > Yes, and even the language used there indicates that this was a short-
> > > sighted way of going about it:

> > > "The XMPPServer/GTalkService really *ONLY* has 2 goals:"  (emphasis
> > > mine).

> > > Clearly you all didn't think this one through to think about how
> > > powerful full XMPP capabilities, down in the core of the system, can
> > > be.  This is an unusual situation, since Googlefolk are usually pretty
> > > well known for thinking through solution sets and how they can be more
> > > powerfully used and dramatically improve the state of the art.
> > > Unfortunately, you seem to have really dropped the ball on this one.

> > > > 1) provide a way to
> > > > efficiently send simple P2P-style messages (in the form of Intents)
> > > between
> > > > handsets, and 2) provide a way to send and receive IMs using Google's
> > > Talk
> > > > servers.  Originally, we intended this service only for our own use.
> > > > However we realized that #1 in particular would be very useful to all
> > > > developers, so we

> Peli

> On Feb 18, 3:56 pm, JMcA <jeff...@gmail.com> wrote:

> > Let me see if I can't give a better reply to this message.

> > So, I've been saying for...I don't know, 3 years or more maybe?...that
> > XMPP had the potential to really become the "Next Great Thing" on the
> > Internet.  And I've been doing system and network administration long
> > enough to remember when the "Next Great Thing" was HTTP/HTML, ok?  I'm
> > talking this sort of level of importance.

> > Let me explain what I mean by that.  XMPP, obviously, is a fantastic
> > technology to build an IM and presense system on, and that has worked
> > very well, and that overall system continues to grow and gain more
> > users.  But XMPP is far, far more capable than just that.  For these 3
> > years or so, I've been advocating to anyone that would listen that
> > XMPP has the potential to be the next big data transport system for
> > the Internet.  The properties are fantastic for it, if people would
> > just realize it and start to make use of it.  Alas, again, I'm not
> > much of a programmer, so I didn't have the skills to develop things
> > that would show this off particularly well.

> > At the risk of buzzword overload, XMPP is (or at least can be) a
> > network-transparent, Internet-scale, platform-neutral, *2-way* (that's
> > important since HTTP basically isn't), secure, reliable, and easy to
> > use IPC and general app communications layer.  The way the current
> > HTTP based systems work, large services that want to build slick
> > interactive applications have to build out large web farms to handle
> > the polling required by techniques like AJAX.  XMPP is much cleaner
> > because it doesn't require polling (although the paradigm can be used
> > within XMPP if the developer wants), thus the scaling demands are much
> > smaller.

> > Anyway, there are people starting to talk about how XMPP can do all of
> > this, now...again, you can search the webternets and find them (some
> > of the guys over at Jive Software have been some of the more active
> > people talking about all this)...and I've been saying this was
> > possible for years, like I said.

> > So, imagine my surprise when I finally take the time to download the
> > Android SDK and emulator, fire it up, start poking at it and playing
> > with it and reading about it and Lo and Behold!  Google has gone and
> > *done* it.  Google has built a system (well, mostly, the XMPPService
> > still needed a little work, but the basics were there) that allows
> > easy agent-level communications between software components in a
> > network transparent and platform neutral way.

> > Then, imagine my disappointment when, five days later, the new SDK is
> > released and Google has done a s/XMPP/GTalk/, and then I go and read
> > the explanation and a couple of things become apparent:

> > 1) This potentially world changing (well, the computing world, anyway)
> > capability came to be basically by *accident*.  Well, ok, there's a
> > long history of inventions, and discoveries happening by accident
> > (penicillin, vulcanized rubber, X-rays...there's plenty more where
> > that came from)
> > 2) *They apparently don't even realize what it is that they've got!*
> > and
> > 3) the planned roadmap is gonna absolutely cripple this by playing
> > walled garden games with it.  Apparently, because of #2, since the
> > googlefolk don't realize the importance of what it is that they've
> > developed here, they're not considering how important this is to be
> > treated with respect, and they're about to wall it off into a walled
> > garden, not realizing the damage that they're going to do in the
> > process.  Ok, maybe Google's walls for their walled garden are lower
> > than typical walled gardens, but its still a walled garden and walled
> > gardens are evil.

> > There's a lot of really cool stuff in Android.  Its pretty slick, lots
> > of eye candy, the Intent and IntentReceiver stuff looks like a pretty
> > slick programming paradigm (again, I'm not really a programmer so I'm
> > not the best judge of that).  Overall its quite cool, but none of that
> > stuff is really revolutionary.  Its all just evolutionary...a big jump
> > in evolution, to be sure, but still just evolutionary.

> > But XMPP as a core system service that can be used as an IPC system++,
> > now *THAT* could possibly change the computing world.  And you all are
> > getting ready to trash it with your further roadmap, because *NOTHING*
> > will kill this possibility faster than playing walled garden games
> > with it, and make no bones about it, you can talk all you want about
> > making things more efficient, and mobile phone cpu and battery and
> > rationalize it all you want, and your rationalizations may even be
> > based on real issues (though I think XMPP can be considerably more
> > efficient than you give it credit), but you're still building a walled
> > garden.

> > Oh, and one more point, you'll notice that I basically haven't said
> > anything about this being about mobile phones.  That's very
> > intentional.  This isn't just about mobile phones.  Though Android is
> > designed for mobile phone use, of course, and its interesting that
> > this is first developing in a product designed for mobile phones,
> > which is about the last place I expected it, but this possible
> > revolution is about *all* of computing.

> > So, people are creating apps that pass Intents around, and we're
> > starting to see people playing with sending Intents from one Android
> > to another.  But think about the possibilities of sending Intents from
> > your Android handset to your KDE desktop (or Gnome, or Windows, or Mac
> > OS X...I said KDE to start with because that's what I personally use
> > for my desktop), or maybe sending Intents from your Android handset to
> > your company's groupware server, or collaboration server, or custom
> > written apps in an app server (JBoss, Glassfish, whatever offering MS
> > has in this space, and the like).

> > The possibilities here are endless, and the implications go far beyond
> > just how competitive the mobile phone handset market is.

> > Take it out of the com.google namespace, this needs to be core to
> > Android (android.net.xmpp ?), this is the single most important
> > feature that Android has to offer the world, please don't kill it
> > because you don't realize the possibilities of it.

> > I know a lot of this sounds melodramatic and full of hyperbole.  Its
> > not.  Take a step back and think about what you're doing, here.

> > On Feb 16, 3:06 pm, "Dan Morrill" <morri...@google.com> wrote:

> > > Hi, Jeff!

> > > It looks like you've misunderstood one of the key issues.  There has been no
> > > change to the "core" of Android at all.

> > > As Dianne also mentioned elsewhere in this thread, neither the old nor new
> > > services are part of the set of libraries for Android.  They are both in a
> > > com.google.* package, and as such are part of the optional Google APIs that
> > > may not be present on all Android devices.  Please check out this page in
> > > the documentation for more details:http://code.google.com/android/toolbox/google-apis.html

> > > In other words, neither the old nor new services are part of Android; they
> > > are part of Google's application software suite that we are creating for
> > > Android.  We are exposing the functionality of the GTalkService as a
> > > courtesy to other developers, because it seems generally useful.  However,
> > > since the service is a third-party library provided by Google and tied to
> > > Google's Talk servers, we're optimizing that software to work well with our
> > > servers.

> > > Best,

> > > - Dan

> > > On Sat, Feb 16, 2008 at 9:07 AM, JMcA <jeff...@gmail.com> wrote:

> > > > > We renamed the service because it is actually not compatible with XMPP,
> > > > and
> > > > > is currently hard-coded to Google's servers anyway.  It would be wrong
> > > > for
> > > > > us to call it "XMPPService" when it isn't really compatible with XMPP,
> > > > so we
> > > > > renamed it GTalkService to prevent confusion.

> > > > Right...so its broken, and it needs to be fixed.  Moving away from a
> > > > standards based protocol to something proprietary is a *really* bad
> > > > idea.

> > > > Maybe if you want to make an

> org.openintents.xmpp would certainly be better than nothing or a
> crippled com.google.GTalkService (or whatever it is).  It looks like
> you all are doing some really cool stuff as well, and building on the
> idea of intents over xmpp for a lot of your work to show the power of
> this type of setup.

> I do think, however, that ultimately this really needs to be part of
> the core system rather than a 3rd party add-on.  Part of the power of
> this sort of capability comes from it being ubiquitously available and
> visible.  As a 3rd party add-on, I fear (despite the good work you all
> are doing) that it will get relegated to a niche capability that
> doesn't every really see the level of support and understanding of the
> power that it really deserves.

> I don't want to discourage your work...like I said, its definitely
> better than the crippled GTalkService, and maybe google will see what
> is being done in the openintents.org world and that will help them see
> and realize what it is that they have built...maybe even merging your
> org.openintents.xmpp code into the core as android.net.xmpp?  I don't
> know if that'll happen, but its certainly one possible good outcome
> among many possible good outcomes!

> On Feb 18, 10:09 am, Peli <peli0...@googlemail.com> wrote:

> > You've convinced me :-)
> > Could you live with org.openintents.xmpp?

> > Peli

> > On Feb 18, 3:56 pm, JMcA <jeff...@gmail.com> wrote:

> > > Let me see if I can't give a better reply to this message.

> > > So, I've been saying for...I don't know, 3 years or more maybe?...that
> > > XMPP had the potential to really become the "Next Great Thing" on the
> > > Internet.  And I've been doing system and network administration long
> > > enough to remember when the "Next Great Thing" was HTTP/HTML, ok?  I'm
> > > talking this sort of level of importance.

> > > Let me explain what I mean by that.  XMPP, obviously, is a fantastic
> > > technology to build an IM and presense system on, and that has worked
> > > very well, and that overall system continues to grow and gain more
> > > users.  But XMPP is far, far more capable than just that.  For these 3
> > > years or so, I've been advocating to anyone that would listen that
> > > XMPP has the potential to be the next big data transport system for
> > > the Internet.  The properties are fantastic for it, if people would
> > > just realize it and start to make use of it.  Alas, again, I'm not
> > > much of a programmer, so I didn't have the skills to develop things
> > > that would show this off particularly well.

> > > At the risk of buzzword overload, XMPP is (or at least can be) a
> > > network-transparent, Internet-scale, platform-neutral, *2-way* (that's
> > > important since HTTP basically isn't), secure, reliable, and easy to
> > > use IPC and general app communications layer.  The way the current
> > > HTTP based systems work, large services that want to build slick
> > > interactive applications have to build out large web farms to handle
> > > the polling required by techniques like AJAX.  XMPP is much cleaner
> > > because it doesn't require polling (although the paradigm can be used
> > > within XMPP if the developer wants), thus the scaling demands are much
> > > smaller.

> > > Anyway, there are people starting to talk about how XMPP can do all of
> > > this, now...again, you can search the webternets and find them (some
> > > of the guys over at Jive Software have been some of the more active
> > > people talking about all this)...and I've been saying this was
> > > possible for years, like I said.

> > > So, imagine my surprise when I finally take the time to download the
> > > Android SDK and emulator, fire it up, start poking at it and playing
> > > with it and reading about it and Lo and Behold!  Google has gone and
> > > *done* it.  Google has built a system (well, mostly, the XMPPService
> > > still needed a little work, but the basics were there) that allows
> > > easy agent-level communications between software components in a
> > > network transparent and platform neutral way.

> > > Then, imagine my disappointment when, five days later, the new SDK is
> > > released and Google has done a s/XMPP/GTalk/, and then I go and read
> > > the explanation and a couple of things become apparent:

> > > 1) This potentially world changing (well, the computing world, anyway)
> > > capability came to be basically by *accident*.  Well, ok, there's a
> > > long history of inventions, and discoveries happening by accident
> > > (penicillin, vulcanized rubber, X-rays...there's plenty more where
> > > that came from)
> > > 2) *They apparently don't even realize what it is that they've got!*
> > > and
> > > 3) the planned roadmap is gonna absolutely cripple this by playing
> > > walled garden games with it.  Apparently, because of #2, since the
> > > googlefolk don't realize the importance of what it is that they've
> > > developed here, they're not considering how important this is to be
> > > treated with respect, and they're about to wall it off into a walled
> > > garden, not realizing the damage that they're going to do in the
> > > process.  Ok, maybe Google's walls for their walled garden are lower
> > > than typical walled gardens, but its still a walled garden and walled
> > > gardens are evil.

> > > There's a lot of really cool stuff in Android.  Its pretty slick, lots
> > > of eye candy, the Intent and IntentReceiver stuff looks like a pretty
> > > slick programming paradigm (again, I'm not really a programmer so I'm
> > > not the best judge of that).  Overall its quite cool, but none of that
> > > stuff is really revolutionary.  Its all just evolutionary...a big jump
> > > in evolution, to be sure, but still just evolutionary.

> > > But XMPP as a core system service that can be used as an IPC system++,
> > > now *THAT* could possibly change the computing world.  And you all are
> > > getting ready to trash it with your further roadmap, because *NOTHING*
> > > will kill this possibility faster than playing walled garden games
> > > with it, and make no bones about it, you can talk all you want about
> > > making things more efficient, and mobile phone cpu and battery and
> > > rationalize it all you want, and your rationalizations may even be
> > > based on real issues (though I think XMPP can be considerably more
> > > efficient than you give it credit), but you're still building a walled
> > > garden.

> > > Oh, and one more point, you'll notice that I basically haven't said
> > > anything about this being about mobile phones.  That's very
> > > intentional.  This isn't just about mobile phones.  Though Android is
> > > designed for mobile phone use, of course, and its interesting that
> > > this is first developing in a product designed for mobile phones,
> > > which is about the last place I expected it, but this possible
> > > revolution is about *all* of computing.

> > > So, people are creating apps that pass Intents around, and we're
> > > starting to see people playing with sending Intents from one Android
> > > to another.  But think about the possibilities of sending Intents from
> > > your Android handset to your KDE desktop (or Gnome, or Windows, or Mac
> > > OS X...I said KDE to start with because that's what I personally use
> > > for my desktop), or maybe sending Intents from your Android handset to
> > > your company's groupware server, or collaboration server, or custom
> > > written apps in an app server (JBoss, Glassfish, whatever offering MS
> > > has in this space, and the like).

> > > The possibilities here are endless, and the implications go far beyond
> > > just how competitive the mobile phone handset market is.

> > > Take it out of the com.google namespace, this needs to be core to
> > > Android (android.net.xmpp ?), this is the single most important
> > > feature that Android has to offer the world, please don't kill it
> > > because you don't

> I think, Google is going a very consequent way from the very beginning
> in this point to strive for efficiency with loss of compatibility:
> They didn't like the Java virtual machine - they replaced it with
> Dalvik. They thought Java Swing is not good enough for the 3D GUI they
> envisioned - they created the Android graphics manager with animation
> and OpenGL. And now they think XMPP is bloated too much, they reduce
> it to GTalk.

> It remains to be seen whether the benefits outweigh the disadvantages.
> Google's XMPP service was restricted to Google servers from day 1, so
> one could suspect from the beginning that they did not want to
> completely open that service. Now they made that point clear at least.

> If users like the improved GTalk and think that it is much faster,
> better, saves bandwidth and what not, then I personally don't really
> see a problem.

> If on the other hand the advantages of an open protocol in connection
> with different servers, services, and applications as you mentioned
> impress people enough, I don't fear being shipped as "3rd party add-
> on". A famous example is the Firefox browser. Not being integrated
> into Windows didn't stop its success. (not that I would dare to
> compare our starting project to the browser legend... ;-) )

> If GTalk proves to be faster and better, I'd probably use it myself,
> and be the last one to stick to communistic principles ("we have to
> force everyone to use open standards").
> (personally I think network latency will render mini-compression of a
> small protocol quite useless so that I also think the open standard
> wins, but I don't know what amount of data Google is planning to send
> over GTalk.. maybe 3D video?)

> Peli

> On Feb 18, 5:09 pm, JMcA <jeff...@gmail.com> wrote:
> > My apologies if I sounded like I was giving you short shrift.  That
> > certainly wasn't my intention.  :)

> > org.openintents.xmpp would certainly be better than nothing or a
> > crippled com.google.GTalkService (or whatever it is).  It looks like
> > you all are doing some really cool stuff as well, and building on the
> > idea of intents over xmpp for a lot of your work to show the power of
> > this type of setup.

> > I do think, however, that ultimately this really needs to be part of
> > the core system rather than a 3rd party add-on.  Part of the power of
> > this sort of capability comes from it being ubiquitously available and
> > visible.  As a 3rd party add-on, I fear (despite the good work you all
> > are doing) that it will get relegated to a niche capability that
> > doesn't every really see the level of support and understanding of the
> > power that it really deserves.

> > I don't want to discourage your work...like I said, its definitely
> > better than the crippled GTalkService, and maybe google will see what
> > is being done in the openintents.org world and that will help them see
> > and realize what it is that they have built...maybe even merging your
> > org.openintents.xmpp code into the core as android.net.xmpp?  I don't
> > know if that'll happen, but its certainly one possible good outcome
> > among many possible good outcomes!

> > On Feb 18, 10:09 am, Peli <peli0...@googlemail.com> wrote:

> > > You've convinced me :-)
> > > Could you live with org.openintents.xmpp?

> > > Peli

> > > On Feb 18, 3:56 pm, JMcA <jeff...@gmail.com> wrote:

> > > > Let me see if I can't give a better reply to this message.

> > > > So, I've been saying for...I don't know, 3 years or more
> maybe?...that
> > > > XMPP had the potential to really become the "Next Great Thing" on
> the
> > > > Internet.  And I've been doing system and network administration
> long
> > > > enough to remember when the "Next Great Thing" was HTTP/HTML, ok?
>  I'm
> > > > talking this sort of level of importance.

> > > > Let me explain what I mean by that.  XMPP, obviously, is a fantastic
> > > > technology to build an IM and presense system on, and that has
> worked
> > > > very well, and that overall system continues to grow and gain more
> > > > users.  But XMPP is far, far more capable than just that.  For these
> 3
> > > > years or so, I've been advocating to anyone that would listen that
> > > > XMPP has the potential to be the next big data transport system for
> > > > the Internet.  The properties are fantastic for it, if people would
> > > > just realize it and start to make use of it.  Alas, again, I'm not
> > > > much of a programmer, so I didn't have the skills to develop things
> > > > that would show this off particularly well.

> > > > At the risk of buzzword overload, XMPP is (or at least can be) a
> > > > network-transparent, Internet-scale, platform-neutral, *2-way*
> (that's
> > > > important since HTTP basically isn't), secure, reliable, and easy to
> > > > use IPC and general app communications layer.  The way the current
> > > > HTTP based systems work, large services that want to build slick
> > > > interactive applications have to build out large web farms to handle
> > > > the polling required by techniques like AJAX.  XMPP is much cleaner
> > > > because it doesn't require polling (although the paradigm can be
> used
> > > > within XMPP if the developer wants), thus the scaling demands are
> much
> > > > smaller.

> > > > Anyway, there are people starting to talk about how XMPP can do all
> of
> > > > this, now...again, you can search the webternets and find them (some
> > > > of the guys over at Jive Software have been some of the more active
> > > > people talking about all this)...and I've been saying this was
> > > > possible for years, like I said.

> > > > So, imagine my surprise when I finally take the time to download the
> > > > Android SDK and emulator, fire it up, start poking at it and playing
> > > > with it and reading about it and Lo and Behold!  Google has gone and
> > > > *done* it.  Google has built a system (well, mostly, the XMPPService
> > > > still needed a little work, but the basics were there) that allows
> > > > easy agent-level communications between software components in a
> > > > network transparent and platform neutral way.

> > > > Then, imagine my disappointment when, five days later, the new SDK
> is
> > > > released and Google has done a s/XMPP/GTalk/, and then I go and read
> > > > the explanation and a couple of things become apparent:

> > > > 1) This potentially world changing (well, the computing world,
> anyway)
> > > > capability came to be basically by *accident*.  Well, ok, there's a
> > > > long history of inventions, and discoveries happening by accident
> > > > (penicillin, vulcanized rubber, X-rays...there's plenty more where
> > > > that came from)
> > > > 2) *They apparently don't even realize what it is that they've got!*
> > > > and
> > > > 3) the planned roadmap is gonna absolutely cripple this by playing
> > > > walled garden games with it.  Apparently, because of #2, since the
> > > > googlefolk don't realize the importance of what it is that they've
> > > > developed here, they're not considering how important this is to be
> > > > treated with respect, and they're about to wall it off into a walled
> > > > garden, not realizing the damage that they're going to do in the
> > > > process.  Ok, maybe Google's walls for their walled garden are lower
> > > > than typical walled gardens, but its still a walled garden and
> walled
> > > > gardens are evil.

> > > > There's a lot of really cool stuff in Android.  Its pretty slick,
> lots
> > > > of eye candy, the Intent and IntentReceiver stuff looks like a
> pretty
> > > > slick programming paradigm (again, I'm not really a programmer so
> I'm
> > > > not the best judge of that).  Overall its quite cool, but none of
> that
> > > > stuff is really revolutionary.  Its all just evolutionary...a big
> jump
> > > > in evolution, to be sure, but still just evolutionary.

> > > > But XMPP as a core system service that can be used as an IPC
> system++,
> > > > now *THAT* could possibly change the computing world.  And you all
> are
> > > > getting ready to trash it with your further roadmap, because
> *NOTHING*
> > > > will kill this possibility faster than playing walled garden games
> > > > with it, and make no bones about it, you can talk all you want about
> > > > making things more efficient, and mobile phone cpu and battery and
> > > > rationalize it all you want, and your rationalizations may even be
> > > > based on real issues (though I think XMPP can be considerably more
> > > > efficient than you give it credit), but you're still building a
> walled
> > > > garden.

> > > > Oh, and one more point, you'll notice that I basically haven't said
> > > > anything about this being about mobile phones.  That's very
> > > > intentional.  This isn't just about mobile phones.  Though Android
> is
> > > > designed for mobile phone use, of course, and its interesting that
> > > > this is first developing in a product designed for mobile phones,
> > > > which is about the last place I expected it, but this possible
> > > > revolution is about *all* of computing.

> > > > So, people are creating apps that pass Intents around, and we're
> > > > starting to see people playing with sending Intents from one Android
> > > > to another.  But think about the

> So, I've been saying for...I don't know, 3 years or more maybe?...that
> XMPP had the potential to really become the "Next Great Thing" on the
> Internet.  And I've been doing system and network administration long
> enough to remember when the "Next Great Thing" was HTTP/HTML, ok?  I'm
> talking this sort of level of importance.

> Let me explain what I mean by that.  XMPP, obviously, is a fantastic
> technology to build an IM and presense system on, and that has worked
> very well, and that overall system continues to grow and gain more
> users.  But XMPP is far, far more capable than just that.  For these 3
> years or so, I've been advocating to anyone that would listen that
> XMPP has the potential to be the next big data transport system for
> the Internet.  The properties are fantastic for it, if people would
> just realize it and start to make use of it.  Alas, again, I'm not
> much of a programmer, so I didn't have the skills to develop things
> that would show this off particularly well.

> At the risk of buzzword overload, XMPP is (or at least can be) a
> network-transparent, Internet-scale, platform-neutral, *2-way* (that's
> important since HTTP basically isn't), secure, reliable, and easy to
> use IPC and general app communications layer.  The way the current
> HTTP based systems work, large services that want to build slick
> interactive applications have to build out large web farms to handle
> the polling required by techniques like AJAX.  XMPP is much cleaner
> because it doesn't require polling (although the paradigm can be used
> within XMPP if the developer wants), thus the scaling demands are much
> smaller.

> Anyway, there are people starting to talk about how XMPP can do all of
> this, now...again, you can search the webternets and find them (some
> of the guys over at Jive Software have been some of the more active
> people talking about all this)...and I've been saying this was
> possible for years, like I said.

> So, imagine my surprise when I finally take the time to download the
> Android SDK and emulator, fire it up, start poking at it and playing
> with it and reading about it and Lo and Behold!  Google has gone and
> *done* it.  Google has built a system (well, mostly, the XMPPService
> still needed a little work, but the basics were there) that allows
> easy agent-level communications between software components in a
> network transparent and platform neutral way.

> Then, imagine my disappointment when, five days later, the new SDK is
> released and Google has done a s/XMPP/GTalk/, and then I go and read
> the explanation and a couple of things become apparent:

> 1) This potentially world changing (well, the computing world, anyway)
> capability came to be basically by *accident*.  Well, ok, there's a
> long history of inventions, and discoveries happening by accident
> (penicillin, vulcanized rubber, X-rays...there's plenty more where
> that came from)
> 2) *They apparently don't even realize what it is that they've got!*
> and
> 3) the planned roadmap is gonna absolutely cripple this by playing
> walled garden games with it.  Apparently, because of #2, since the
> googlefolk don't realize the importance of what it is that they've
> developed here, they're not considering how important this is to be
> treated with respect, and they're about to wall it off into a walled
> garden, not realizing the damage that they're going to do in the
> process.  Ok, maybe Google's walls for their walled garden are lower
> than typical walled gardens, but its still a walled garden and walled
> gardens are evil.

> There's a lot of really cool stuff in Android.  Its pretty slick, lots
> of eye candy, the Intent and IntentReceiver stuff looks like a pretty
> slick programming paradigm (again, I'm not really a programmer so I'm
> not the best judge of that).  Overall its quite cool, but none of that
> stuff is really revolutionary.  Its all just evolutionary...a big jump
> in evolution, to be sure, but still just evolutionary.

> But XMPP as a core system service that can be used as an IPC system++,
> now *THAT* could possibly change the computing world.  And you all are
> getting ready to trash it with your further roadmap, because *NOTHING*
> will kill this possibility faster than playing walled garden games
> with it, and make no bones about it, you can talk all you want about
> making things more efficient, and mobile phone cpu and battery and
> rationalize it all you want, and your rationalizations may even be
> based on real issues (though I think XMPP can be considerably more
> efficient than you give it credit), but you're still building a walled
> garden.

> Oh, and one more point, you'll notice that I basically haven't said
> anything about this being about mobile phones.  That's very
> intentional.  This isn't just about mobile phones.  Though Android is
> designed for mobile phone use, of course, and its interesting that
> this is first developing in a product designed for mobile phones,
> which is about the last place I expected it, but this possible
> revolution is about *all* of computing.

> So, people are creating apps that pass Intents around, and we're
> starting to see people playing with sending Intents from one Android
> to another.  But think about the possibilities of sending Intents from
> your Android handset to your KDE desktop (or Gnome, or Windows, or Mac
> OS X...I said KDE to start with because that's what I personally use
> for my desktop), or maybe sending Intents from your Android handset to
> your company's groupware server, or collaboration server, or custom
> written apps in an app server (JBoss, Glassfish, whatever offering MS
> has in this space, and the like).

> The possibilities here are endless, and the implications go far beyond
> just how competitive the mobile phone handset market is.

> Take it out of the com.google namespace, this needs to be core to
> Android (android.net.xmpp ?), this is the single most important
> feature that Android has to offer the world, please don't kill it
> because you don't realize the possibilities of it.

> I know a lot of this sounds melodramatic and full of hyperbole.  Its
> not.  Take a step back and think about what you're doing, here.

> On Feb 16, 3:06 pm, "Dan Morrill" <morri...@google.com> wrote:

> > Hi, Jeff!

> > It looks like you've misunderstood one of the key issues.  There has been no
> > change to the "core" of Android at all.

> > As Dianne also mentioned elsewhere in this thread, neither the old nor new
> > services are part of the set of libraries for Android.  They are both in a
> > com.google.* package, and as such are part of the optional Google APIs that
> > may not be present on all Android devices.  Please check out this page in
> > the documentation for more details:http://code.google.com/android/toolbox/google-apis.html

> > In other words, neither the old nor new services are part of Android; they
> > are part of Google's application software suite that we are creating for
> > Android.  We are exposing the functionality of the GTalkService as a
> > courtesy to other developers, because it seems generally useful.  However,
> > since the service is a third-party library provided by Google and tied to
> > Google's Talk servers, we're optimizing that software to work well with our
> > servers.

> > Best,

> > - Dan

> > On Sat, Feb 16, 2008 at 9:07 AM, JMcA <jeff...@gmail.com> wrote:

> > > > We renamed the service because it is actually not compatible with XMPP,
> > > and
> > > > is currently hard-coded to Google's servers anyway.  It would be wrong
> > > for
> > > > us to call it "XMPPService" when it isn't really compatible with XMPP,
> > > so we
> > > > renamed it GTalkService to prevent confusion.

> > > Right...so its broken, and it needs to be fixed.  Moving away from a
> > > standards based protocol to something proprietary is a *really* bad
> > > idea.

> > > Maybe if you want to make an *additional* connection method that can
> > > work between android and gtalk available that supposedly will be more
> > > efficient, that might be a good idea.  But removing (or, I guess,
> > > moving away from) the ability to do standards compliant XMPP is the
> > > wrong direction.

> > > Tieing android to the gtalk server smacks of a walled garden
> > > attitude.  "Don't Be Evil" says that you should run, not walk, in the
> > > other direction.

> > > On Feb 15, 7:58 pm, "Dan Morrill" <morri...@google.com> wrote:
> > > > The XMPPService/GTalkService really only has 2 goals:

> > > Yes, and even the language used there indicates that this was a short-
> > > sighted way of going about it:

> > > "The XMPPServer/GTalkService really *ONLY* has 2 goals:"  (emphasis
> > > mine).

> > > Clearly you all didn't think this one through to think about how
> > > powerful full XMPP capabilities, down in the core of the system, can
> > > be.  This is an unusual situation, since Googlefolk are usually pretty
> > > well known for thinking through solution sets and how they can be more
> > > powerfully used and dramatically improve the state of the art.
> > > Unfortunately, you seem to have really dropped the ball on this one.

> > > > 1) provide a way to
> > > > efficiently send simple P2P-style messages (in the form of Intents)
> > > between
> > > > handsets, and 2)