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.
Does anyone else have any more information on this topic? Does this
mean that in effect anyone using an android handset with an
application that planed on using xmpp would now be locked to a gtalk
account? From my point of view and for what I would like to do with
android, the single most important piece of android is XMPP because it
allows my applications to receive push messages without http polling
and all of it's associated problems.
This switch to gtalk, which will effectively lock all android handset
xmpp communications to gtalk network is very troubling indeed. In fact
my this may very well kill the viability of an application that I am
building if this is the case.
Mike
On Feb 15, 8:03 am, Muthu Ramadoss <muthu.ramad...@gmail.com> wrote:
> 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.
On 2/15/08, Muthu Ramadoss <muthu.ramad...@gmail.com> wrote:
> 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?
"Not the ideal solution, but is there something about the protocol
that says the community can't develop its own implementation?"
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.
But I could easily be mistaken here, and really hope that I am as I am
still learning about android. Perhaps it might be possible to include
an XMPP client inside of my application and still be able to receive
notifications from a server without too many side effects.
Mike
On Feb 15, 9:37 am, "Wink Saville" <w...@saville.com> wrote:
> On 2/15/08, Muthu Ramadoss <muthu.ramad...@gmail.com> wrote:
> > 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?
mikeb wrote: > "Not the ideal solution, but is there something about the protocol > that says the community can't develop its own implementation?"
> 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.
Interesting question; if we assume Android is open enough and XMPP is desirable then I'd disagree and say the likely hood is much higher than nil. But I understand your point if Google includes it then this isn't an issue.
> But I could easily be mistaken here, and really hope that I am as I am > still learning about android. Perhaps it might be possible to include > an XMPP client inside of my application and still be able to receive > notifications from a server without too many side effects.
> Mike
We also need to understand why they've decided to drop it? Guess, XMPP threatens SMS revenue streams, by going proprietary Google and the vendors have more control of the revenue model. It will be interesting to see if the new scheme will be open or not.
Agree, I would like to see googletalk as default IM application on
adroid platform, but I thought that it would be installed as separate
application (or set of API) on the platform and would use
"com.google.android.xmppService" package classes like all other 3rtd
party programs - remember "All applications are equal" from the
introduction video of Android platform.
"com.google.android.xmppService" - is a generic API for XMPP access -
just like org.apache.http.* package for comfortable work with HTTP.
GTalk should be built over this API separately, even if it would be
included in the main platform (and as I have said, I would like to see
it there - just like API for SMS and MMS access).
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.
On Feb 15, 7:03 pm, Muthu Ramadoss <muthu.ramad...@gmail.com> wrote:
> 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.
As mikeb already pointed out, the XMPPService was renamed to GTalkService. The functionality should be largely the same.
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.
Is there something missing from GTalkService that you need to do build your application?
- Dan
On Fri, Feb 15, 2008 at 8:03 AM, Muthu Ramadoss <muthu.ramad...@gmail.com> wrote:
> 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.
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.
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...
> 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.
Sorry folks, this thread is just getting sillier by the minute. *IF* google does not want to do this, why can't you all get together and implement *exactly* the same API that was there in the previous rev with exact same semantics.
After all (1), we know exactly what was used to implement this API [1] and we have prototype code that worked in the previous SDK [2].
After all (2), this is supposed to be an "open source" platform
Is there really an itch here or just a wish that someone else (google) should shoulder the burden...
| 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. | | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin)
