Python and Java - equal siblings under Wave?

[roschler]

Will Python and Java be equal siblings under Wave, or will one
language always be slightly favored over the other? By favored I mean
being always one step ahead of the other language in API breadth and
latest new feature support, and in available documentation, debugging
facilities, and tutorial support.

Not to read to much into this but, I noticed that the Python Client
tutorial was not available yet while the Java Client already had one.
I was surprised by this of course since everyone knows of Google's
fondness for Python. But with Java being supported by AppEngine now,
and the GWT being based on Java, I wonder if there is a sea change
occurring that might be important. I know both languages but I prefer
Python. However if Java is going to have the edge with Wave, it might
be prudent to shift my focus to Java and save some time in the
process.

What say you?

Thanks,
Robert
http://www.robodance.com/
http://twitter.com/roschler

[RickB]

I asked the same question about 6 seconds later. ;-)

[sco...@google.com]

Hi there. We have every intention of having Java and Python be equal
in Wave. The current state of tutorials is only due to the Java API
being developed first. If you look deeper, you will notice that the
Python API exposes a lower level API of events and operations, while
the Java API is a little higher level maintaining the "effective"
state of the Wave on the Robot client. It is our plan to expose both
layers and even describe the wire protocol such that developers can
use their language of choice to develop with Wave.

Seth

[roschler]

RickB,

LOL. The first case of parallel independent Waves?

Robert

[Jorge Vargas]

Hi Seth,

On May 30, 8:39 pm, "scov...@google.com" <scov...@google.com> wrote:
> Hi there. We have every intention of having Java and Python be equal
> in Wave. The current state of tutorials is only due to the Java API
> being developed first. If you look deeper, you will notice that the
> Python API exposes a lower level API of events and operations, while
> the Java API is a little higher level maintaining the "effective"
> state of the Wave on the Robot client. It is our plan to expose both
> layers and even describe the wire protocol such that developers can
> use their language of choice to develop with Wave.
>

I kindly disagree, I got two feeling about this that did not point me
to your conclusion. Please (and I'll really love to be disproved here)
tell me why I'm wrong.

a- This is totally unpythonic. From what I can tell the whole robot-
python-client is coded this way.

def Setup(context):
"""Called when this robot is first added to the wave."""
root_wavelet = context.GetRootWavelet()
root_wavelet.CreateBlip().GetDocument().SetText("I'm alive!")

b- from wave-robot-python-client-read-only/src/waveapi/util.py

def CollapseJavaCollections(data):
"""Collapses the unnecessary extra data structures in the wire
format.

Currently the wire format is built from marshalling of Java objects.
This
introduces overhead of extra key/value pairs with respect to
collections and
superfluous fields. As such, this method attempts to collapse those
structures
out of the data format by collapsing the collection objects and
removing
the java class fields.

This preserves the data that is passed in and only removes the
collection
types.

Args:
data: Some arbitrary dict, list or primitive type.

Returns:
The same data structure with the collapsed and unnecessary objects
removed.
"""
if IsDict(data):
java_class = data.get('javaClass')
if java_class:
del data['javaClass']
if java_class == 'java.util.HashMap':
return CollapseJavaCollections(data['map'])
elif java_class == 'java.util.ArrayList':
return CollapseJavaCollections(data['list'])
for key, val in data.iteritems():
data[key] = CollapseJavaCollections(val)
elif IsListOrDict(data):
for index in range(len(data)):
data[index] = CollapseJavaCollections(data[index])
return data
return data

Those two arguments lead me to believe the python API was build on top
of rather than from the ground up.

This is really sad for me specially because the java version (sadly as
most java) seems total bloatware (just compare the java examples with
the python ones) not to mention that http://code.google.com/apis/wave/extensions/robots/guide.html
is more a leason on how to make eclipse work than a real tutorial.

Sorry for the tone, this got me really down after 48hrs of O M G

[Bastian Hoyer]

I don't see the problem. Those api's are only example implementations.
When they publish the documentation of the underlying protocol you can
create your own java/python/php/perl/ruby library the way you want.

Remember that this is an early stage preview and the underlying
protocol still changes and until it is stable it don't make much sense
to put to much efford into those libs.

[Jorge Vargas]

Hi,

On Sun, May 31, 2009 at 4:59 AM, Bastian Hoyer <daf...@gmail.com> wrote:
>
> I don't see the problem. Those api's are only example implementations.
> When they publish the documentation of the underlying protocol you can
> create your own java/python/php/perl/ruby library the way you want.
>

That is not correct. the robots are part of the google wave client,
and as far as I know those are the same robots used by the demo.

> Remember that this is an early stage preview and the underlying
> protocol still changes and until it is stable it don't make much sense
> to put to much efford into those libs.

Again you have not understood the system client-server is one thing
server-server is another and client-gadget|robot is another. They are
3 different sets of communications, and that code I'm referring to
(according to them not me) is the api for robots for their client.

> >
>

[Bastian Hoyer]

On 1 Jun., 00:28, Jorge Vargas <jorge.var...@gmail.com> wrote:
> Hi,
>
> On Sun, May 31, 2009 at 4:59 AM, Bastian Hoyer <daf...@gmail.com> wrote:
>
> > I don't see the problem. Those api's are only example implementations.
> > When they publish the documentation of the underlying protocol you can
> > create your own java/python/php/perl/ruby library the way you want.
>
> That is not correct. the robots are part of the google wave client,
> and as far as I know those are the same robots used by the demo.

No. The Robots never communicate with the wave client directly. The
Robot is like any other participent of the Wave and communicates
directly with the Server. The wave server does http calls to robots
calling events to which the robot can respond. Those calls are XML
that is parsed by the client library. If you want you can create such
a library in any language that can respond to http calls. (For the
developer preview those web apps can only use app engine but that will
change)

http://code.google.com/intl/en/apis/wave/extensions/robots/index.html

> Again you have not understood the system client-server is one thing
> server-server is another and client-gadget|robot is another. They are
> 3 different sets of communications, and that code I'm referring to
> (according to them not me) is the api for robots for their client.

There are no robots for the client. The only API for the client is the
Gadget API, which don't use Python or Java but Javascript.

http://code.google.com/intl/en/apis/wave/extensions/gadgets/reference.html

[Seth Covitz]

Jorge, thanks for the feedback and please keep it coming. We are working to address these issues.

Seth

[Seth Covitz]

Thanks for clarifying. Bastian is indeed correct. Robots are server-side components even though they appear as participants in your client.

Seth

[David Byttow]

I just want to jump in here and re-iterate one point, specifically for Jorge.

These two apis are *not* first-class citizens of Wave. They are still a work and progress, both from a protocol and API standpoint. In my opinion (having written the bulk of the Python API), I see them as much as out-of-the-box frameworks as I do "examples" how to communicate with Wave servers.

Once the protocol solidifies a bit, there is nothing stopping anyone from writing their own frameworks. And I can't wait to see what people come up with!

David

[Bastian Hoyer]

@david: just wanted to thank you that you added the python api besides
the java one ;)

[Jorge Vargas]

This is actually awesome news for some reason I though the robots
where restricted to the client. Thanks for correcting me. That makes
them even more awesome.

[Jorge Vargas]

On Mon, Jun 1, 2009 at 4:58 PM, David Byttow <david...@google.com> wrote:
> I just want to jump in here and re-iterate one point, specifically for
> Jorge.
>

Awesome, thanks for correcting me :)

> These two apis are *not* first-class citizens of Wave. They are still a work
> and progress, both from a protocol and API standpoint. In my opinion (having
> written the bulk of the Python API), I see them as much as out-of-the-box
> frameworks as I do "examples" how to communicate with Wave servers.
>

yea I totally got that from the code the python one is pretty much a
XML->objects converter. What really threw me off in this line of
though was actually a comment "Currently the wire format is built from
marshalling of Java objects." which pretty much means we have a lot of
type information on the wire. I know "Currently" on that sentence
means it will change, and I really like that. But at the moment I it
indeed seems "simpler" to talk java to the protocol than python, but
we all know python is simpler by several orders of magnitude :p

> Once the protocol solidifies a bit, there is nothing stopping anyone from
> writing their own frameworks. And I can't wait to see what people come up
> with!

yea I can totally see that happening although I can tell you I really
like your implementation looks very clean and nice. Just that the anti
pep8 hurts my eyes (another indication of the above conclusion :p)

Anyway keep up the good work and I'll be here waiting to throw a ton
of bots at you.

[Matt Mason]

I for one would really like to see a C# library.  .Net is the game in my corp, and that's where all the developer brainshare is as well.  I can see that I should implement it and make it available to the community.  Anyone interested in working with me on that?

[Andrew Douglas]

Correct me if I'm wrong, in fact I'm sure I'm wrong... but wouldn't it be feasible to build xmpp components that act as bots... added as participants and provided with the same events and features as these custom api's provide? If so, any language, including .net, that had libraries for building xmpp components could feasibly build bots. Sure, there would be some work there, but that seems like a perfectly valid approach to me and even begs the question - why build a another "component" architecture when xmpp's already got one.
-Andrew

[Bastian Hoyer]

well ... the disadvantage with a xmpp component would be that those
would have to be running processes that are connected to the server
all the time. they also would need some kind of authentication and
accounts for bots in that case when the robot is the connecting
component instead of the server. hosting a web application that is
called from the server is easier and cheaper.