The whitepaper at http://www.waveprotocol.org/whitepapers/internal-client-server-protocol describes the information exchanged between the client and server - but it does not specify any format to that. I guess currently the communication is based on HTTP and the data is probably exchanged as XML or JSON between the Javascript runtime in the users browser and the server. Is that correct? Do you have any plans to formalize that? I imagine that this is an analogue to POP3 or IMAP.
On Sun, Jul 26, 2009 at 1:33 PM, Zbigniew Lukasiak <zzb...@gmail.com> wrote:
> Hi there,
> The whitepaper at
> http://www.waveprotocol.org/whitepapers/internal-client-server-protocol > describes the information exchanged between the client and server -
> but it does not specify any format to that. I guess currently the
> communication is based on HTTP and the data is probably exchanged as
> XML or JSON between the Javascript runtime in the users browser and
> the server. Is that correct? Do you have any plans to formalize
> that? I imagine that this is an analogue to POP3 or IMAP.
This is something that came up a number of times at the Wave
Federation day. The process of formalising a client-server protocol is
interesting, but it's not something that Google has even started
considering...
On Sun, Jul 26, 2009 at 01:03, Zbigniew Lukasiak<zzb...@gmail.com> wrote:
> Hi there,
> The whitepaper at
> http://www.waveprotocol.org/whitepapers/internal-client-server-protocol > describes the information exchanged between the client and server -
> but it does not specify any format to that. I guess currently the
> communication is based on HTTP and the data is probably exchanged as
> XML or JSON between the Javascript runtime in the users browser and
> the server. Is that correct? Do you have any plans to formalize
> that? I imagine that this is an analogue to POP3 or IMAP.
Cutpiecewala<hussuspec...@gmail.com> wrote: > Hello there. > You are partially right.. > Wave is working on xmtp protocol. > It is based on exchanging xml information between client and server. > Hussain.
no. the xmpp protocol is only used for server to server communication.
Cutpiecewala<hussuspec...@gmail.com> wrote: > Hello there. > You are partially right.. > Wave is working on xmtp protocol. > It is based on exchanging xml information between client and server.
On Sun, Jul 26, 2009 at 04:49, Zbigniew Lukasiak<zzb...@gmail.com> wrote:
> On Sun, Jul 26, 2009 at 1:38 PM, Hussain
> Cutpiecewala<hussuspec...@gmail.com> wrote:
>> Hello there.
>> You are partially right..
>> Wave is working on xmtp protocol.
>> It is based on exchanging xml information between client and server.
> Aha - so you mean the client-server protocol is the same as the
> server-server (as described in
> http://www.waveprotocol.org/draft-protocol-spec) protocol? I assume
> you mean XMPP (as in the mentioned spec), and not XMTP (which is some
> obscure mail protocol: http://www.openhealth.org/xmtp/) - am I right?
I hate to keep harping on this topic but its one that I know a lot of people
are interested in....
Will the reference implementation of the client (when it is released) work
on Google's public Wave service?
It may seem like an obvious question, but I'd still like further
clarification. My presumption has always been: Yes, of course it will.
That's what you guys showed at I/O and that's kinda what a reference
implementation implies? Right?
But after learning more about this, I'm not nearly so certain and would
really like to know for sure.
Since, as you say, it's just 'protobufs over the wire', I can easily see how
c/s interactions would be very release specific, and could easily diverage
accross server implementations. In addition, it was mentioned at FedDay
that the prototype used some OT that was different from the sandbox. I can
easily see how a reference implementation could evolve quite separate from
the sandbox (or the public service, when that goes live). Especially since
Google does all sorts of fancy pants optimizations on their front end that
I'd never expect in a ref impl.
Based on what I've heard and read, one of the things I expect (hope?) to
see with Wave is a proliferation of clients along the lines of all the
Twitter clients that are available today for twitter.com. But without an
explicit, documented c/s protocol I can see how this might not ever happen.
I know you also said that this having a c/s protocol was an objective that
you're working toward (and solicted community assitance with), but knowing
if the client ref impl will work on the sandbox and public wave service is a
different question that I'd like to understand more completely.
Thanks
CM
On Sun, Jul 26, 2009 at 10:50 PM, Anthony Baxter <anthonybax...@gmail.com>wrote:
> Currently the client server protocol is just protobufs over the wire.
> On Sun, Jul 26, 2009 at 04:49, Zbigniew Lukasiak<zzb...@gmail.com> wrote:
> > On Sun, Jul 26, 2009 at 1:38 PM, Hussain
> > Cutpiecewala<hussuspec...@gmail.com> wrote:
> >> Hello there.
> >> You are partially right..
> >> Wave is working on xmtp protocol.
> >> It is based on exchanging xml information between client and server.
> > Aha - so you mean the client-server protocol is the same as the
> > server-server (as described in
> > http://www.waveprotocol.org/draft-protocol-spec) protocol? I assume
> > you mean XMPP (as in the mentioned spec), and not XMTP (which is some
> > obscure mail protocol: http://www.openhealth.org/xmtp/) - am I right?
I think the shower answer to your questions, Chris, is - for now - no.
However, I don't think that prohibits a standard c/s protocol.
My analogy is this: the Google Talk gadget inside your GMail client
doesn't necessarily talk client/server XMPP, however we still expose
an alternative XMPP port and are still happy for you to have a
fully-fledged XMPP client connect to that.
As Anthony has said, the client/server protocol is not something we've
started considering. If a standard becomes obvious, I think Google
would happily adhere to it, in the spirit of any emerging Wave
community. As a side note, consider that Google's focus is on the web,
and it wouldn't be unfair to say that we still think the best way to
present Wave to our users is through a hosted web application.
> I hate to keep harping on this topic but its one that I know a lot of people
> are interested in....
> Will the reference implementation of the client (when it is released) work
> on Google's public Wave service?
> It may seem like an obvious question, but I'd still like further
> clarification. My presumption has always been: Yes, of course it will.
> That's what you guys showed at I/O and that's kinda what a reference
> implementation implies? Right?
> But after learning more about this, I'm not nearly so certain and would
> really like to know for sure.
> Since, as you say, it's just 'protobufs over the wire', I can easily see how
> c/s interactions would be very release specific, and could easily diverage
> accross server implementations. In addition, it was mentioned at FedDay
> that the prototype used some OT that was different from the sandbox. I can
> easily see how a reference implementation could evolve quite separate from
> the sandbox (or the public service, when that goes live). Especially since
> Google does all sorts of fancy pants optimizations on their front end that
> I'd never expect in a ref impl.
> Based on what I've heard and read, one of the things I expect (hope?) to
> see with Wave is a proliferation of clients along the lines of all the
> Twitter clients that are available today for twitter.com. But without an
> explicit, documented c/s protocol I can see how this might not ever happen.
> I know you also said that this having a c/s protocol was an objective that
> you're working toward (and solicted community assitance with), but knowing
> if the client ref impl will work on the sandbox and public wave service is a
> different question that I'd like to understand more completely.
> Thanks
> CM
> On Sun, Jul 26, 2009 at 10:50 PM, Anthony Baxter <anthonybax...@gmail.com>
> wrote:
>> Currently the client server protocol is just protobufs over the wire.
>> On Sun, Jul 26, 2009 at 04:49, Zbigniew Lukasiak<zzb...@gmail.com> wrote:
>> > On Sun, Jul 26, 2009 at 1:38 PM, Hussain
>> > Cutpiecewala<hussuspec...@gmail.com> wrote:
>> >> Hello there.
>> >> You are partially right..
>> >> Wave is working on xmtp protocol.
>> >> It is based on exchanging xml information between client and server.
>> > Aha - so you mean the client-server protocol is the same as the
>> > server-server (as described in
>> > http://www.waveprotocol.org/draft-protocol-spec) protocol? I assume
>> > you mean XMPP (as in the mentioned spec), and not XMTP (which is some
>> > obscure mail protocol: http://www.openhealth.org/xmtp/) - am I right?
> I think the shower answer to your questions, Chris, is - for now - no.
> However, I don't think that prohibits a standard c/s protocol.
> My analogy is this: the Google Talk gadget inside your GMail client
> doesn't necessarily talk client/server XMPP, however we still expose
> an alternative XMPP port and are still happy for you to have a
> fully-fledged XMPP client connect to that.
> As Anthony has said, the client/server protocol is not something we've
> started considering. If a standard becomes obvious, I think Google
> would happily adhere to it, in the spirit of any emerging Wave
> community. As a side note, consider that Google's focus is on the web,
> and it wouldn't be unfair to say that we still think the best way to
> present Wave to our users is through a hosted web application.
> On Tue, Jul 28, 2009 at 23:32, Chris
> Marino<christopher.c.mar...@gmail.com> wrote:
> > Anthony,
> > I hate to keep harping on this topic but its one that I know a lot of
> people
> > are interested in....
> > Will the reference implementation of the client (when it is released)
> work
> > on Google's public Wave service?
> > It may seem like an obvious question, but I'd still like further
> > clarification. My presumption has always been: Yes, of course it will.
> > That's what you guys showed at I/O and that's kinda what a reference
> > implementation implies? Right?
> > But after learning more about this, I'm not nearly so certain and would
> > really like to know for sure.
> > Since, as you say, it's just 'protobufs over the wire', I can easily see
> how
> > c/s interactions would be very release specific, and could easily
> diverage
> > accross server implementations. In addition, it was mentioned at FedDay
> > that the prototype used some OT that was different from the sandbox. I
> can
> > easily see how a reference implementation could evolve quite separate
> from
> > the sandbox (or the public service, when that goes live). Especially
> since
> > Google does all sorts of fancy pants optimizations on their front end
> that
> > I'd never expect in a ref impl.
> > Based on what I've heard and read, one of the things I expect (hope?) to
> > see with Wave is a proliferation of clients along the lines of all the
> > Twitter clients that are available today for twitter.com. But without an
> > explicit, documented c/s protocol I can see how this might not ever
> happen.
> > I know you also said that this having a c/s protocol was an objective
> that
> > you're working toward (and solicted community assitance with), but
> knowing
> > if the client ref impl will work on the sandbox and public wave service
> is a
> > different question that I'd like to understand more completely.
> > Thanks
> > CM
> > On Sun, Jul 26, 2009 at 10:50 PM, Anthony Baxter <
> anthonybax...@gmail.com>
> > wrote:
> >> Currently the client server protocol is just protobufs over the wire.
> >> On Sun, Jul 26, 2009 at 04:49, Zbigniew Lukasiak<zzb...@gmail.com>
> wrote:
> >> > On Sun, Jul 26, 2009 at 1:38 PM, Hussain
> >> > Cutpiecewala<hussuspec...@gmail.com> wrote:
> >> >> Hello there.
> >> >> You are partially right..
> >> >> Wave is working on xmtp protocol.
> >> >> It is based on exchanging xml information between client and
> server.
> >> > Aha - so you mean the client-server protocol is the same as the
> >> > server-server (as described in
> >> > http://www.waveprotocol.org/draft-protocol-spec) protocol? I assume
> >> > you mean XMPP (as in the mentioned spec), and not XMTP (which is some
> >> > obscure mail protocol: http://www.openhealth.org/xmtp/) - am I right?
There's still about two months to go until we plan to open our final
Federation port, and have our consumer preview release. That's a
fairly long time to look to at least beginning to standardise the
client/server protocol.
Marino<christopher.c.mar...@gmail.com> wrote:
> Thanks Sam, I sort of expected this answer. I'm not thrilled with it, but
> it's much better to know, than not know.
> CM
> On Tue, Jul 28, 2009 at 4:02 PM, Sam Thorogood <sam.thorog...@gmail.com>
> wrote:
>> I think the shower answer to your questions, Chris, is - for now - no.
>> However, I don't think that prohibits a standard c/s protocol.
>> My analogy is this: the Google Talk gadget inside your GMail client
>> doesn't necessarily talk client/server XMPP, however we still expose
>> an alternative XMPP port and are still happy for you to have a
>> fully-fledged XMPP client connect to that.
>> As Anthony has said, the client/server protocol is not something we've
>> started considering. If a standard becomes obvious, I think Google
>> would happily adhere to it, in the spirit of any emerging Wave
>> community. As a side note, consider that Google's focus is on the web,
>> and it wouldn't be unfair to say that we still think the best way to
>> present Wave to our users is through a hosted web application.
>> On Tue, Jul 28, 2009 at 23:32, Chris
>> Marino<christopher.c.mar...@gmail.com> wrote:
>> > Anthony,
>> > I hate to keep harping on this topic but its one that I know a lot of
>> > people
>> > are interested in....
>> > Will the reference implementation of the client (when it is released)
>> > work
>> > on Google's public Wave service?
>> > It may seem like an obvious question, but I'd still like further
>> > clarification. My presumption has always been: Yes, of course it will.
>> > That's what you guys showed at I/O and that's kinda what a reference
>> > implementation implies? Right?
>> > But after learning more about this, I'm not nearly so certain and would
>> > really like to know for sure.
>> > Since, as you say, it's just 'protobufs over the wire', I can easily see
>> > how
>> > c/s interactions would be very release specific, and could easily
>> > diverage
>> > accross server implementations. In addition, it was mentioned at
>> > FedDay
>> > that the prototype used some OT that was different from the sandbox. I
>> > can
>> > easily see how a reference implementation could evolve quite separate
>> > from
>> > the sandbox (or the public service, when that goes live). Especially
>> > since
>> > Google does all sorts of fancy pants optimizations on their front end
>> > that
>> > I'd never expect in a ref impl.
>> > Based on what I've heard and read, one of the things I expect (hope?)
>> > to
>> > see with Wave is a proliferation of clients along the lines of all the
>> > Twitter clients that are available today for twitter.com. But without an
>> > explicit, documented c/s protocol I can see how this might not ever
>> > happen.
>> > I know you also said that this having a c/s protocol was an objective
>> > that
>> > you're working toward (and solicted community assitance with), but
>> > knowing
>> > if the client ref impl will work on the sandbox and public wave service
>> > is a
>> > different question that I'd like to understand more completely.
>> > Thanks
>> > CM
>> > On Sun, Jul 26, 2009 at 10:50 PM, Anthony Baxter
>> > <anthonybax...@gmail.com>
>> > wrote:
>> >> Currently the client server protocol is just protobufs over the wire.
>> >> On Sun, Jul 26, 2009 at 04:49, Zbigniew Lukasiak<zzb...@gmail.com>
>> >> wrote:
>> >> > On Sun, Jul 26, 2009 at 1:38 PM, Hussain
>> >> > Cutpiecewala<hussuspec...@gmail.com> wrote:
>> >> >> Hello there.
>> >> >> You are partially right..
>> >> >> Wave is working on xmtp protocol.
>> >> >> It is based on exchanging xml information between client and
>> >> >> server.
>> >> > Aha - so you mean the client-server protocol is the same as the
>> >> > server-server (as described in
>> >> > http://www.waveprotocol.org/draft-protocol-spec) protocol? I assume
>> >> > you mean XMPP (as in the mentioned spec), and not XMTP (which is some
>> >> > obscure mail protocol: http://www.openhealth.org/xmtp/) - am I right?
> There's still about two months to go until we plan to open our final
> Federation port, and have our consumer preview release. That's a
> fairly long time to look to at least beginning to standardise the
> client/server protocol.
> On Wed, Jul 29, 2009 at 10:02, Chris
> Marino<christopher.c.mar...@gmail.com> wrote:
> > Thanks Sam, I sort of expected this answer. I'm not thrilled with it, but
> > it's much better to know, than not know.
> > CM
> > On Tue, Jul 28, 2009 at 4:02 PM, Sam Thorogood <sam.thorog...@gmail.com>
> > wrote:
> >> I think the shower answer to your questions, Chris, is - for now - no.
> >> However, I don't think that prohibits a standard c/s protocol.
> >> My analogy is this: the Google Talk gadget inside your GMail client
> >> doesn't necessarily talk client/server XMPP, however we still expose
> >> an alternative XMPP port and are still happy for you to have a
> >> fully-fledged XMPP client connect to that.
> >> As Anthony has said, the client/server protocol is not something we've
> >> started considering. If a standard becomes obvious, I think Google
> >> would happily adhere to it, in the spirit of any emerging Wave
> >> community. As a side note, consider that Google's focus is on the web,
> >> and it wouldn't be unfair to say that we still think the best way to
> >> present Wave to our users is through a hosted web application.
> >> On Tue, Jul 28, 2009 at 23:32, Chris
> >> Marino<christopher.c.mar...@gmail.com> wrote:
> >> > Anthony,
> >> > I hate to keep harping on this topic but its one that I know a lot of
> >> > people
> >> > are interested in....
> >> > Will the reference implementation of the client (when it is released)
> >> > work
> >> > on Google's public Wave service?
> >> > It may seem like an obvious question, but I'd still like further
> >> > clarification. My presumption has always been: Yes, of course it
> will.
> >> > That's what you guys showed at I/O and that's kinda what a reference
> >> > implementation implies? Right?
> >> > But after learning more about this, I'm not nearly so certain and
> would
> >> > really like to know for sure.
> >> > Since, as you say, it's just 'protobufs over the wire', I can easily
> see
> >> > how
> >> > c/s interactions would be very release specific, and could easily
> >> > diverage
> >> > accross server implementations. In addition, it was mentioned at
> >> > FedDay
> >> > that the prototype used some OT that was different from the sandbox.
> I
> >> > can
> >> > easily see how a reference implementation could evolve quite separate
> >> > from
> >> > the sandbox (or the public service, when that goes live). Especially
> >> > since
> >> > Google does all sorts of fancy pants optimizations on their front end
> >> > that
> >> > I'd never expect in a ref impl.
> >> > Based on what I've heard and read, one of the things I expect (hope?)
> >> > to
> >> > see with Wave is a proliferation of clients along the lines of all the
> >> > Twitter clients that are available today for twitter.com. But without
> an
> >> > explicit, documented c/s protocol I can see how this might not ever
> >> > happen.
> >> > I know you also said that this having a c/s protocol was an objective
> >> > that
> >> > you're working toward (and solicted community assitance with), but
> >> > knowing
> >> > if the client ref impl will work on the sandbox and public wave
> service
> >> > is a
> >> > different question that I'd like to understand more completely.
> >> > Thanks
> >> > CM
> >> > On Sun, Jul 26, 2009 at 10:50 PM, Anthony Baxter
> >> > <anthonybax...@gmail.com>
> >> > wrote:
> >> >> Currently the client server protocol is just protobufs over the wire.
> >> >> On Sun, Jul 26, 2009 at 04:49, Zbigniew Lukasiak<zzb...@gmail.com>
> >> >> wrote:
> >> >> > On Sun, Jul 26, 2009 at 1:38 PM, Hussain
> >> >> > Cutpiecewala<hussuspec...@gmail.com> wrote:
> >> >> >> Hello there.
> >> >> >> You are partially right..
> >> >> >> Wave is working on xmtp protocol.
> >> >> >> It is based on exchanging xml information between client and
> >> >> >> server.
> >> >> > Aha - so you mean the client-server protocol is the same as the
> >> >> > server-server (as described in
> >> >> > http://www.waveprotocol.org/draft-protocol-spec) protocol? I
> assume
> >> >> > you mean XMPP (as in the mentioned spec), and not XMTP (which is
> some
> >> >> > obscure mail protocol: http://www.openhealth.org/xmtp/) - am I
> right?
I would like to add that in order to let the wave protocol become a
widely used standard, I think there is more power in standardizing on
the federation protocol first. Given that Sam offered an analogy,
here's another one: email was driven by SMTP which allowed widespread
adoption of email because everyone could run a server. IMAP or POP
came later, and is still not offered by every email provider. By
providing a prototype wave server, we hope to give more power to
developers and let them take the architecture and run with it -
hopefully we'll allow for a wider adoption base and see all sorts of
creative uses of the wave technology.
Our client/server protocol is in its basic form protocol buffers on
the wire, however we've had to add more complexity to make it work
across the different layers of our architecture. Releasing all of that
right now is not feasible. We're certainly striving to release as much
as we can as soon as we can, but it will take a little time while
we're also working like crazy building out the whole wave system. For
what it's worth, the basic client/server protocol for sharing waves is
pretty close to what is published in the fedone example
(http://code.google.com/p/wave-protocol/source/browse/src/org/waveprot...)
- to which we've added a few optimizations for our production system.
Why not use that as a starting point, and as more people start running
wave servers, we can work on a common standard ?
On Tue, Jul 28, 2009 at 5:07 PM, Sam Thorogood<sam.thorog...@gmail.com> wrote:
> I don't think it's actually a bad answer :)
> There's still about two months to go until we plan to open our final
> Federation port, and have our consumer preview release. That's a
> fairly long time to look to at least beginning to standardise the
> client/server protocol.
> On Wed, Jul 29, 2009 at 10:02, Chris
> Marino<christopher.c.mar...@gmail.com> wrote:
>> Thanks Sam, I sort of expected this answer. I'm not thrilled with it, but
>> it's much better to know, than not know.
>> CM
>> On Tue, Jul 28, 2009 at 4:02 PM, Sam Thorogood <sam.thorog...@gmail.com>
>> wrote:
>>> I think the shower answer to your questions, Chris, is - for now - no.
>>> However, I don't think that prohibits a standard c/s protocol.
>>> My analogy is this: the Google Talk gadget inside your GMail client
>>> doesn't necessarily talk client/server XMPP, however we still expose
>>> an alternative XMPP port and are still happy for you to have a
>>> fully-fledged XMPP client connect to that.
>>> As Anthony has said, the client/server protocol is not something we've
>>> started considering. If a standard becomes obvious, I think Google
>>> would happily adhere to it, in the spirit of any emerging Wave
>>> community. As a side note, consider that Google's focus is on the web,
>>> and it wouldn't be unfair to say that we still think the best way to
>>> present Wave to our users is through a hosted web application.
>>> On Tue, Jul 28, 2009 at 23:32, Chris
>>> Marino<christopher.c.mar...@gmail.com> wrote:
>>> > Anthony,
>>> > I hate to keep harping on this topic but its one that I know a lot of
>>> > people
>>> > are interested in....
>>> > Will the reference implementation of the client (when it is released)
>>> > work
>>> > on Google's public Wave service?
>>> > It may seem like an obvious question, but I'd still like further
>>> > clarification. My presumption has always been: Yes, of course it will.
>>> > That's what you guys showed at I/O and that's kinda what a reference
>>> > implementation implies? Right?
>>> > But after learning more about this, I'm not nearly so certain and would
>>> > really like to know for sure.
>>> > Since, as you say, it's just 'protobufs over the wire', I can easily see
>>> > how
>>> > c/s interactions would be very release specific, and could easily
>>> > diverage
>>> > accross server implementations. In addition, it was mentioned at
>>> > FedDay
>>> > that the prototype used some OT that was different from the sandbox. I
>>> > can
>>> > easily see how a reference implementation could evolve quite separate
>>> > from
>>> > the sandbox (or the public service, when that goes live). Especially
>>> > since
>>> > Google does all sorts of fancy pants optimizations on their front end
>>> > that
>>> > I'd never expect in a ref impl.
>>> > Based on what I've heard and read, one of the things I expect (hope?)
>>> > to
>>> > see with Wave is a proliferation of clients along the lines of all the
>>> > Twitter clients that are available today for twitter.com. But without an
>>> > explicit, documented c/s protocol I can see how this might not ever
>>> > happen.
>>> > I know you also said that this having a c/s protocol was an objective
>>> > that
>>> > you're working toward (and solicted community assitance with), but
>>> > knowing
>>> > if the client ref impl will work on the sandbox and public wave service
>>> > is a
>>> > different question that I'd like to understand more completely.
>>> > Thanks
>>> > CM
>>> > On Sun, Jul 26, 2009 at 10:50 PM, Anthony Baxter
>>> > <anthonybax...@gmail.com>
>>> > wrote:
>>> >> Currently the client server protocol is just protobufs over the wire.
>>> >> On Sun, Jul 26, 2009 at 04:49, Zbigniew Lukasiak<zzb...@gmail.com>
>>> >> wrote:
>>> >> > On Sun, Jul 26, 2009 at 1:38 PM, Hussain
>>> >> > Cutpiecewala<hussuspec...@gmail.com> wrote:
>>> >> >> Hello there.
>>> >> >> You are partially right..
>>> >> >> Wave is working on xmtp protocol.
>>> >> >> It is based on exchanging xml information between client and
>>> >> >> server.
>>> >> > Aha - so you mean the client-server protocol is the same as the
>>> >> > server-server (as described in
>>> >> > http://www.waveprotocol.org/draft-protocol-spec) protocol? I assume
>>> >> > you mean XMPP (as in the mentioned spec), and not XMTP (which is some
>>> >> > obscure mail protocol: http://www.openhealth.org/xmtp/) - am I right?
Thanks for the answers. Maybe I should state from where I come - I am thinking about an independent implementation of Wave.
On Wed, Jul 29, 2009 at 3:05 AM, Jochen Bekmann<joc...@google.com> wrote:
> I would like to add that in order to let the wave protocol become a > widely used standard, I think there is more power in standardizing on > the federation protocol first. Given that Sam offered an analogy, > here's another one: email was driven by SMTP which allowed widespread > adoption of email because everyone could run a server. IMAP or POP > came later, and is still not offered by every email provider. By > providing a prototype wave server, we hope to give more power to > developers and let them take the architecture and run with it - > hopefully we'll allow for a wider adoption base and see all sorts of > creative uses of the wave technology.
I think you miss something in that analogy - even before email servers were connected to one another (with SMPT) there always were ways to receive the emails locally and read it in the client. With wave there is no such way.
From my point of view there is no way I could use the federation protocol if I cannot read the waves anyway - but the opposite situation where I had a way to read waves but no way to send them to other servers would be quite functional and perhaps could make an interesting social networking application.
The only thing I'm afraid of is that we get a bunch of wave servers
and clients that have different feature sets, like servers with and
without robot support, clients that don't support gadgets or no markup
and stuff like that .)
One thing I wonder is which server is responsible to speak to robots
in a wave... is it always the wave server of the person who created
the wave ? Or, if we think of spell checking robot is it the server of
the current user ?
On Wed, Jul 29, 2009 at 09:20, Zbigniew Lukasiak<zzb...@gmail.com> wrote:
> Hi there,
> Thanks for the answers. Maybe I should state from where I come - I am
> thinking about an independent implementation of Wave.
> On Wed, Jul 29, 2009 at 3:05 AM, Jochen Bekmann<joc...@google.com> wrote:
>> I would like to add that in order to let the wave protocol become a
>> widely used standard, I think there is more power in standardizing on
>> the federation protocol first. Given that Sam offered an analogy,
>> here's another one: email was driven by SMTP which allowed widespread
>> adoption of email because everyone could run a server. IMAP or POP
>> came later, and is still not offered by every email provider. By
>> providing a prototype wave server, we hope to give more power to
>> developers and let them take the architecture and run with it -
>> hopefully we'll allow for a wider adoption base and see all sorts of
>> creative uses of the wave technology.
> I think you miss something in that analogy - even before email servers
> were connected to one another (with SMPT) there always were ways to
> receive the emails locally and read it in the client. With wave there
> is no such way.
> From my point of view there is no way I could use the federation
> protocol if I cannot read the waves anyway - but the opposite
> situation where I had a way to read waves but no way to send them to
> other servers would be quite functional and perhaps could make an
> interesting social networking application.
Wouldn't it be which ever wave provider that owns the aliasing domain
name that the robot lives on.
For example, the appspot.com robots are controlled by the google wave
provider if the robot was f...@bar.com then the WSP that federated on
behalf of bar.com would be responsible for speak to that particular
robot.
> The only thing I'm afraid of is that we get a bunch of wave servers
> and clients that have different feature sets, like servers with and
> without robot support, clients that don't support gadgets or no markup
> and stuff like that .)
> One thing I wonder is which server is responsible to speak to robots
> in a wave... is it always the wave server of the person who created
> the wave ? Or, if we think of spell checking robot is it the server of
> the current user ?
> On Wed, Jul 29, 2009 at 09:20, Zbigniew Lukasiak<zzb...@gmail.com> wrote:
>> Hi there,
>> Thanks for the answers. Maybe I should state from where I come - I am
>> thinking about an independent implementation of Wave.
>> On Wed, Jul 29, 2009 at 3:05 AM, Jochen Bekmann<joc...@google.com> wrote:
>>> I would like to add that in order to let the wave protocol become a
>>> widely used standard, I think there is more power in standardizing on
>>> the federation protocol first. Given that Sam offered an analogy,
>>> here's another one: email was driven by SMTP which allowed widespread
>>> adoption of email because everyone could run a server. IMAP or POP
>>> came later, and is still not offered by every email provider. By
>>> providing a prototype wave server, we hope to give more power to
>>> developers and let them take the architecture and run with it -
>>> hopefully we'll allow for a wider adoption base and see all sorts of
>>> creative uses of the wave technology.
>> I think you miss something in that analogy - even before email servers
>> were connected to one another (with SMPT) there always were ways to
>> receive the emails locally and read it in the client. With wave there
>> is no such way.
>> From my point of view there is no way I could use the federation
>> protocol if I cannot read the waves anyway - but the opposite
>> situation where I had a way to read waves but no way to send them to
>> other servers would be quite functional and perhaps could make an
>> interesting social networking application.
Bastian Hoyer wrote: > The only thing I'm afraid of is that we get a bunch of wave servers > and clients that have different feature sets, like servers with and > without robot support, clients that don't support gadgets or no markup > and stuff like that .)
> One thing I wonder is which server is responsible to speak to robots > in a wave... is it always the wave server of the person who created > the wave ? Or, if we think of spell checking robot is it the server of > the current user ?
My guess would be which ever server is hosting the robot. Remember Robots count as participants, so would need a host server to be able to take part in a federated Wave.
On the different servers and clients with differing feature sets, I say why not? So long as they all talk the same underlying language and can communicate with each other then bring it on. Competition leads to innovation leads to a better Wave.
That's kinda the point. Right now, we're still unsure what a
client-server protocol should look like. This is not just going to be
driven by the needs of Google's current web frontend, but of all the
other clients I'm sure people are thinking up.
When I and other googlers have said "there's no concrete client-server
protocol", you can attach an unspoken "yet" to that. We don't know
what it should look like in it's final form. On the other hand, we
have a fair idea about the requirements and needs of the federation
protocol, which is why we took at stab at writing that down first.
If anyone has ideas about what this should look like based on what
they've seen so far, start a discussion on it. It's not necessary for
Google to come down the mountain with a completed standard engraved in
stone. Or even in something softer, like soap.
On Wed, Jul 29, 2009 at 06:34, James Purser<jamesrpur...@gmail.com> wrote:
> Bastian Hoyer wrote:
>> The only thing I'm afraid of is that we get a bunch of wave servers
>> and clients that have different feature sets, like servers with and
>> without robot support, clients that don't support gadgets or no markup
>> and stuff like that .)
>> One thing I wonder is which server is responsible to speak to robots
>> in a wave... is it always the wave server of the person who created
>> the wave ? Or, if we think of spell checking robot is it the server of
>> the current user ?
> My guess would be which ever server is hosting the robot. Remember
> Robots count as participants, so would need a host server to be able to
> take part in a federated Wave.
> On the different servers and clients with differing feature sets, I say
> why not? So long as they all talk the same underlying language and can
> communicate with each other then bring it on. Competition leads to
> innovation leads to a better Wave.
On Wed, Jul 29, 2009 at 12:20 AM, Zbigniew Lukasiak<zzb...@gmail.com> wrote:
> Hi there,
> Thanks for the answers. Maybe I should state from where I come - I am
> thinking about an independent implementation of Wave.
> On Wed, Jul 29, 2009 at 3:05 AM, Jochen Bekmann<joc...@google.com> wrote:
>> I would like to add that in order to let the wave protocol become a
>> widely used standard, I think there is more power in standardizing on
>> the federation protocol first. Given that Sam offered an analogy,
>> here's another one: email was driven by SMTP which allowed widespread
>> adoption of email because everyone could run a server. IMAP or POP
>> came later, and is still not offered by every email provider. By
>> providing a prototype wave server, we hope to give more power to
>> developers and let them take the architecture and run with it -
>> hopefully we'll allow for a wider adoption base and see all sorts of
>> creative uses of the wave technology.
> I think you miss something in that analogy - even before email servers
> were connected to one another (with SMPT) there always were ways to
> receive the emails locally and read it in the client. With wave there
> is no such way.
Admittedly there is no _standard_ way to retrieve the messages, but
there certainly is a way. As pointed out, our released code's
client/server protocol closely matches our production client/server
protocol, and is quite sufficient for reading and exchanging messages
locally ? (Similarly, as I understand it, prior to SMTP there were
various non-standard ways different systems implemented email).
> From my point of view there is no way I could use the federation
> protocol if I cannot read the waves anyway - but the opposite
> situation where I had a way to read waves but no way to send them to
> other servers would be quite functional and perhaps could make an
> interesting social networking application.
Anthony Baxter wrote: > That's kinda the point. Right now, we're still unsure what a > client-server protocol should look like. This is not just going to be > driven by the needs of Google's current web frontend, but of all the > other clients I'm sure people are thinking up.
> When I and other googlers have said "there's no concrete client-server > protocol", you can attach an unspoken "yet" to that. We don't know > what it should look like in it's final form. On the other hand, we > have a fair idea about the requirements and needs of the federation > protocol, which is why we took at stab at writing that down first.
> If anyone has ideas about what this should look like based on what > they've seen so far, start a discussion on it. It's not necessary for > Google to come down the mountain with a completed standard engraved in > stone. Or even in something softer, like soap.
Okay, just to confirm something, by using Protobuf (Java or Python) it should be possible to use the .proto files that come with the WRS to build a new interface correct?
Given that the clients will probably need to cache waves, and should really
be performing OT as well, i dont see why, like was suggested a few weeks ago
by some one else, the federation protocol cant be used as at least a
starting point for the protocol?
On Thu, Jul 30, 2009 at 2:10 PM, James Purser <jamesrpur...@gmail.com>wrote:
> Anthony Baxter wrote:
> > That's kinda the point. Right now, we're still unsure what a
> > client-server protocol should look like. This is not just going to be
> > driven by the needs of Google's current web frontend, but of all the
> > other clients I'm sure people are thinking up.
> > When I and other googlers have said "there's no concrete client-server
> > protocol", you can attach an unspoken "yet" to that. We don't know
> > what it should look like in it's final form. On the other hand, we
> > have a fair idea about the requirements and needs of the federation
> > protocol, which is why we took at stab at writing that down first.
> > If anyone has ideas about what this should look like based on what
> > they've seen so far, start a discussion on it. It's not necessary for
> > Google to come down the mountain with a completed standard engraved in
> > stone. Or even in something softer, like soap.
> Okay, just to confirm something, by using Protobuf (Java or Python) it
> should be possible to use the .proto files that come with the WRS to
> build a new interface correct?
At what point do you think googlers will release their code for the
current web-frontend used for the sandbox.
I would really like to see it (as I am sure many others would!)
On 30 July, 07:23, Damian Guppy <the.d...@gmail.com> wrote:
> Given that the clients will probably need to cache waves, and should really
> be performing OT as well, i dont see why, like was suggested a few weeks ago
> by some one else, the federation protocol cant be used as at least a
> starting point for the protocol?
> On Thu, Jul 30, 2009 at 2:10 PM, James Purser <jamesrpur...@gmail.com>wrote:
> > Anthony Baxter wrote:
> > > That's kinda the point. Right now, we're still unsure what a
> > > client-server protocol should look like. This is not just going to be
> > > driven by the needs of Google's current web frontend, but of all the
> > > other clients I'm sure people are thinking up.
> > > When I and other googlers have said "there's no concrete client-server
> > > protocol", you can attach an unspoken "yet" to that. We don't know
> > > what it should look like in it's final form. On the other hand, we
> > > have a fair idea about the requirements and needs of the federation
> > > protocol, which is why we took at stab at writing that down first.
> > > If anyone has ideas about what this should look like based on what
> > > they've seen so far, start a discussion on it. It's not necessary for
> > > Google to come down the mountain with a completed standard engraved in
> > > stone. Or even in something softer, like soap.
> > Okay, just to confirm something, by using Protobuf (Java or Python) it
> > should be possible to use the .proto files that come with the WRS to
> > build a new interface correct?
I’d really like to see XMPP used for the client–server protocol. This
is what I assumed when I first heard about Wave, and when I swarmed
into the Sandbox, I was swarming with plans to start implementing a
terminal client in Ruby, a Cocoa client for OS X, and a Cocoa client
for the iPhone.
Unfortunately, I had all my illusion shattered when I found that not
only did Google’s implementation of Wave not use XMPP for anything but
bits of the federation, but that the client–server protocol didn’t
even *exist* yet.
What use will Wave be on release day if nobody releases a client at
the same time? How can I start working feverishly on these clients, to
have them ready by release day, if there is no known protocol for
communicating with Wave servers? /-:
So, yeah, this is my 2¢ for getting an XMPP–based C/S protocol
implemented ASAFP.
On Jul 30, 2:14 pm, Tom Dyer <dye...@googlemail.com> wrote:
> At what point do you think googlers will release their code for the
> current web-frontend used for the sandbox.
> I would really like to see it (as I am sure many others would!)
> On 30 July, 07:23, Damian Guppy <the.d...@gmail.com> wrote:
> > Given that the clients will probably need to cache waves, and should really
> > be performing OT as well, i dont see why, like was suggested a few weeks ago
> > by some one else, the federation protocol cant be used as at least a
> > starting point for the protocol?
> > On Thu, Jul 30, 2009 at 2:10 PM, James Purser <jamesrpur...@gmail.com>wrote:
> > > Anthony Baxter wrote:
> > > > That's kinda the point. Right now, we're still unsure what a
> > > > client-server protocol should look like. This is not just going to be
> > > > driven by the needs of Google's current web frontend, but of all the
> > > > other clients I'm sure people are thinking up.
> > > > When I and other googlers have said "there's no concrete client-server
> > > > protocol", you can attach an unspoken "yet" to that. We don't know
> > > > what it should look like in it's final form. On the other hand, we
> > > > have a fair idea about the requirements and needs of the federation
> > > > protocol, which is why we took at stab at writing that down first.
> > > > If anyone has ideas about what this should look like based on what
> > > > they've seen so far, start a discussion on it. It's not necessary for
> > > > Google to come down the mountain with a completed standard engraved in
> > > > stone. Or even in something softer, like soap.
> > > Okay, just to confirm something, by using Protobuf (Java or Python) it
> > > should be possible to use the .proto files that come with the WRS to
> > > build a new interface correct?
Well, as far as I see it's not so tough to tweak server-server
protocol to be used for c2s interactions.
Roughly, what can be a first try is next:
1.Incorporate FedOne into some gui that will display document editing process.
2.Establish connection with Provider wave server, but make some minor
distinction of connection being C2S, not regular S2S.
3.work with local fedone as client component.
> I’d really like to see XMPP used for the client–server protocol. This
> is what I assumed when I first heard about Wave, and when I swarmed
> into the Sandbox, I was swarming with plans to start implementing a
> terminal client in Ruby, a Cocoa client for OS X, and a Cocoa client
> for the iPhone.
> Unfortunately, I had all my illusion shattered when I found that not
> only did Google’s implementation of Wave not use XMPP for anything but
> bits of the federation, but that the client–server protocol didn’t
> even *exist* yet.
> What use will Wave be on release day if nobody releases a client at
> the same time? How can I start working feverishly on these clients, to
> have them ready by release day, if there is no known protocol for
> communicating with Wave servers? /-:
> So, yeah, this is my 2¢ for getting an XMPP–based C/S protocol
> implemented ASAFP.
> On Jul 30, 2:14 pm, Tom Dyer wrote:
>> At what point do you think googlers will release their code for the
>> current web-frontend used for the sandbox.
>> I would really like to see it (as I am sure many others would!)
>> On 30 July, 07:23, Damian Guppy wrote:
>> > Given that the clients will probably need to cache waves, and should really
>> > be performing OT as well, i dont see why, like was suggested a
few weeks ago
>> > by some one else, the federation protocol cant be used as at least a
>> > starting point for the protocol?
>> > On Thu, Jul 30, 2009 at 2:10 PM, James Purser wrote:
>> > > Anthony Baxter wrote:
>> > > > That's kinda the point. Right now, we're still unsure what a
>> > > > client-server protocol should look like. This is not just going to be
>> > > > driven by the needs of Google's current web frontend, but of all the
>> > > > other clients I'm sure people are thinking up.
>> > > > When I and other googlers have said "there's no concrete client-server
>> > > > protocol", you can attach an unspoken "yet" to that. We don't know
>> > > > what it should look like in it's final form. On the other hand, we
>> > > > have a fair idea about the requirements and needs of the federation
>> > > > protocol, which is why we took at stab at writing that down first.
>> > > > If anyone has ideas about what this should look like based on what
>> > > > they've seen so far, start a discussion on it. It's not necessary for
>> > > > Google to come down the mountain with a completed standard engraved in
>> > > > stone. Or even in something softer, like soap.
>> > > Okay, just to confirm something, by using Protobuf (Java or Python) it
>> > > should be possible to use the .proto files that come with the WRS to
>> > > build a new interface correct?
elliottcable wrote: > I’d really like to see XMPP used for the client–server protocol. This > is what I assumed when I first heard about Wave, and when I swarmed > into the Sandbox, I was swarming with plans to start implementing a > terminal client in Ruby, a Cocoa client for OS X, and a Cocoa client > for the iPhone.
> Unfortunately, I had all my illusion shattered when I found that not > only did Google’s implementation of Wave not use XMPP for anything but > bits of the federation, but that the client–server protocol didn’t > even *exist* yet.
The WRS has a Client-Server protocol. It's in the form of Googles Protocol Buffers which by default can be translated to Java and Python Code. There are also third party implementations to bring the ProtoBuffs to other languages:
might help. There doesn't seem to be a Cocoa compiler, but seeing as this is Open Source, "patches welcome".
I've already converted the .proto files I got with the WRS into python classes and am looking at how to use them.
> What use will Wave be on release day if nobody releases a client at > the same time? How can I start working feverishly on these clients, to > have them ready by release day, if there is no known protocol for > communicating with Wave servers? /-:
> So, yeah, this is my 2¢ for getting an XMPP–based C/S protocol > implemented ASAFP.
While I can see the benefits of using XMPP on the Server->Server side, I'm yet to be convinced that it has anything special over Protobufs for the Client->Server side of things.
Also keep in mind that if you build your own Wave Server/Web Client setup you can use what ever you like between the two.
> While I can see the benefits of using XMPP on the Server->Server side, > I'm yet to be convinced that it has anything special over Protobufs for > the Client->Server side of things.
Informally speaking, protobufs is a wire format, and XMPP is more like what content fields to include in a messages. Of course, it's more than just that, but for discussion I'll mention this side of things.
XMPP allows usage of custom wire formats, like existing different compressions, encodings (you can see protobufs encoding of XMPP stream as a compression)
So, again, roughly speaking, the discussion is more about having stardard or not than what to use as a wire layer.
And if community becomes convinced in advantages of having standard for client-server protocol, why then not to take advantages of existing developed standards, given that they were developed right for the purpose of real-time collaboration?
Probably, standard for client-server protocol can be modularized itself, allowing simple clients to implement only core capabilities, like that we see in current fedone server, and allow other clients implement more sophisticated features with custom OT transformations, like OT for spreadsheets and other complex objects, not only text.
I clearly see advantage of existing xmpp framework for developing client-server protocol over it. Also, if protocol gets discussed publicly on XSF lists, it's more likely it becames more mature and useful, and gets wider codebase and user support.
