Thanks, Mike! We definitely appreciate the feedback.
Here are some additional points that I don't think we've yet spelled out
clearly.
The XMPPService/GTalkService really only has 2 goals: 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.
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. The reasons we are using a different
protocol are generally to reduce bandwidth and processor overhead, and to
improve startup/connection times. So it's not that we don't like XMPP, it's
simply that we are trying to solve a different problem.
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!
Hope that clears things up a little,
- Dan
On Fri, Feb 15, 2008 at 4:18 PM, mikeb <michaelhb
...@gmail.com> wrote:
> 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.
