With the opening of the actual Google Wave preview today, I think it’s
high
time we re–opened the topic of the client–server (C/S) protocol.
As the FAQ for this group says:
> What is the client-server protocol?
> -------------------------------------------------
> The focus of our open source and protocol work at this point is on
> the federation protocol, which is critical for getting inter-operable
> server implementations, that is, for allowing many other people to
> build Wave servers and have them interop with each other and with the
> Google Wave server. We have definitely heard the requests for defining
> a client-server protocol, but at this time the team doesn't have the
> time to put into such an effort.
> If you are interested in working on the client-server protocol we
> are happy to host that discussion here, and the client-server protocol
> as implemented in the open source server would be a fine place to
> start.
Let’s get that discussion started, shall we? Federation is great, a
user
preview that dumb randoms can press pretty HTML buttons on is great,
but Wave
(the concept) is really quite useless until somebody can install a
Wave client
and talk to their Wave server of choice in that client, and read waves
from
other Wave users writing things in their own clients through their own
servers. None of that is possible until we (client developers) can get
started
writing our client libraries, GUI clients, web clients, and
programmatic
clients… and none of *those* are possible until we have a guarantee
that our
hard work and sweaty hours of coding will produce a product that will
be
useful on more than just Google’s Wave server.
No offence to the Google Wave team (everything else they’ve come up
with is
pretty great), but the RPC/protobufs solution is… very much a non–
solution,
really. What, exactly, do we all want to see in this protocol?
I personally am interested in seeing XMPP become not only the
foundation of
the federation protocol, but of the C/S protocol as well. When I first
heard
about Wave, before getting into the Sandbox, I was very excited; it
sounded
like a great idea, based on great tools (XMPP!). Unfortunately, I was
extremely disappointed to find that XMPP really has nothing whatsoever
to do
with Wave, and I’d like to see that remedied.
Really, though, any sensible protocol that we can agree on would be
great.
Another option is possibly something involving JSON; that’d make
JavaScript
heavy–clients ridiculously easy to write for the web.
Please, weigh in, and let’s get this hump over with!
elliottcable wrote:
> With the opening of the actual Google Wave preview today, I think it’s
> high
> time we re–opened the topic of the client–server (C/S) protocol.
> As the FAQ for this group says:
>> What is the client-server protocol?
>> -------------------------------------------------
>> The focus of our open source and protocol work at this point is on
>> the federation protocol, which is critical for getting inter-operable
>> server implementations, that is, for allowing many other people to
>> build Wave servers and have them interop with each other and with the
>> Google Wave server. We have definitely heard the requests for defining
>> a client-server protocol, but at this time the team doesn't have the
>> time to put into such an effort.
>> If you are interested in working on the client-server protocol we
>> are happy to host that discussion here, and the client-server protocol
>> as implemented in the open source server would be a fine place to
>> start.
> Let’s get that discussion started, shall we? Federation is great, a
> user
> preview that dumb randoms can press pretty HTML buttons on is great,
> but Wave
> (the concept) is really quite useless until somebody can install a
> Wave client
> and talk to their Wave server of choice in that client, and read waves
> from
> other Wave users writing things in their own clients through their own
> servers. None of that is possible until we (client developers) can get
> started
> writing our client libraries, GUI clients, web clients, and
> programmatic
> clients… and none of *those* are possible until we have a guarantee
> that our
> hard work and sweaty hours of coding will produce a product that will
> be
> useful on more than just Google’s Wave server.
> No offence to the Google Wave team (everything else they’ve come up
> with is
> pretty great), but the RPC/protobufs solution is… very much a non–
> solution,
> really. What, exactly, do we all want to see in this protocol?
> I personally am interested in seeing XMPP become not only the
> foundation of
> the federation protocol, but of the C/S protocol as well. When I first
> heard
> about Wave, before getting into the Sandbox, I was very excited; it
> sounded
> like a great idea, based on great tools (XMPP!). Unfortunately, I was
> extremely disappointed to find that XMPP really has nothing whatsoever
> to do
> with Wave, and I’d like to see that remedied.
> Really, though, any sensible protocol that we can agree on would be
> great.
> Another option is possibly something involving JSON; that’d make
> JavaScript
> heavy–clients ridiculously easy to write for the web.
> Please, weigh in, and let’s get this hump over with!
> I personally am interested in seeing XMPP become not only the > foundation of > the federation protocol, but of the C/S protocol as well. When I first > heard > about Wave, before getting into the Sandbox, I was very excited; it > sounded > like a great idea, based on great tools (XMPP!). Unfortunately, I was > extremely disappointed to find that XMPP really has nothing whatsoever > to do > with Wave, and I’d like to see that remedied.
I'd be happy to help with an XMPP binding.
> Really, though, any sensible protocol that we can agree on would be > great. > Another option is possibly something involving JSON; that’d make > JavaScript > heavy–clients ridiculously easy to write for the web.
JSON is not extensible. IMHO that's going to make it difficult to build anything interesting.
Based on my investigation so far, it would be possible to create a client/server protocol that is just a special case of the server/server federation protocol. Some of the benefits to using XMPP are: 1. Potential for significant shared code between client/server and federation in FedOne. 2. Authentication is already handled in XMPP so saves the need to add it to FedOne.
With federation FedOne used acknowledgments and a logarithmically increasing delay time for retransmits. The same will work for clients, but can be optimized by allowing the server to receive user presence notifications. It would be expected that an XMPP client would cache wavelet history and as such the server would only send new delta and respond to history and cert requests.
XMPP seems like it should have been adopted and pushed for, cradle to
grave when the words 'real time collaboration' were mentioned.
However, I would not put it past that this protocol will rival XMPP in
terms of flexibility.
> I personally am interested in seeing XMPP become not only the > foundation of the federation protocol, but of the C/S protocol as > well.
Absolutely. It looks as if ProcessOne have already done some work towards this. http://tr.im/p1wave Is anybody from there on this list? It would be great if they were happy to share that work publicly. -- petef
It looks like some people misunderstood the point…
On Oct 1, 6:35 am, James Jones <ja...@freedomnet.co.nz> wrote:
> why not just keep using XMMP?
Wave is *not* using XMPP right now for the C/S protocol. Only for
federation. The point of this discussion is to decide upon a C/S
protocol that doesn’t suck; I am personally lobbying for XMPP to be
said protocol.
On Oct 1, 6:42 am, Peter Saint-Andre <stpe...@stpeter.im> wrote:
> On 10/1/09 2:43 AM, elliottcable wrote:
> > I personally am interested in seeing XMPP become not only the
> > foundation of
> > the federation protocol, but of the C/S protocol as well. When I first
> > heard
> > about Wave, before getting into the Sandbox, I was very excited; it
> > sounded
> > like a great idea, based on great tools (XMPP!). Unfortunately, I was
> > extremely disappointed to find that XMPP really has nothing whatsoever
> > to do
> > with Wave, and I’d like to see that remedied.
> I'd be happy to help with an XMPP binding.
An XMPP ‘binding’? No, we don’t want to bind the existing RPC/protobuf
psuedo–protocol to XMPP, we want to replace it. Google has, multiple
times and places, said it’s very open to yanking out that hacky crap
and replacing it with a protocol that the community can agree on. So,
all that’s left is for us to agree on one, and tell google ‘implement
this.’
On Oct 1, 6:42 am, Peter Saint-Andre <stpe...@stpeter.im> wrote:
> On 10/1/09 2:43 AM, elliottcable wrote:
> > Really, though, any sensible protocol that we can agree on would be
> > great.
> > Another option is possibly something involving JSON; that’d make
> > JavaScript
> > heavy–clients ridiculously easy to write for the web.
> JSON is not extensible. IMHO that's going to make it difficult to build
> anything interesting.
I disagree about JSON not being extensible, but it’s not really my
‘favourite horse’ for this race, anyway.
On Oct 1, 9:41 am, danbirlem <dman....@gmail.com> wrote:
> XMPP seems like it should have been adopted and pushed for, cradle to
> grave when the words 'real time collaboration' were mentioned.
> However, I would not put it past that this protocol will rival XMPP in
> terms of flexibility.
> Just my two cents...
What do you mean by ‘this protocol’? The RPC/protobufs C/S protocol
currently in use? To even call that a protocol is kind of laughable.
Read above, it’s largely irrelevant as long as ‘we the people’ can
agree on a real protocol in a timely manner, so Google doesn’t change
their mind about being willing to use whatever we agree on.
On Oct 1, 10:27 am, Peter Ferne <peter.fe...@gmail.com> wrote:
> On 1 Oct 2009, at 09:43, elliottcable wrote:
> > I personally am interested in seeing XMPP become not only the
> > foundation of the federation protocol, but of the C/S protocol as
> > well.
> Absolutely. It looks as if ProcessOne have already done some work
> towards this.http://tr.im/p1waveIs anybody from there on this list?
> It would be great if they were happy to share that work publicly.
> --
> petef
Hey, that looks pretty relevant. Maybe I’ll try to email some of their
guys with a Google Groups link to this thread later today.
(Also, damn you, Google Groups, for automatically wrapping my text!
I’m so used to hard–wrapping everything I type at 78 characters…
sorry, to everybody else, for producing an original message unreadable
on Google Groups >_<)
I'm gonna also vote for the C/S protocol to use XMPP. I've
successfully implemented XMPP over BOSH and it rocks. In fact, I've
built quite a bit of XEP-60 (the XMPP pubsub protocol - used by Wave)
in JavaScript for use in what you might think of as 'browser-based
client/server apps', so I know it can be done.
As far as the old JSON vs. XML argument - I've run the numbers and it
just doesn't add up. Once you gzip the XML, it can actually be smaller
than the JSON - it doesn't seem possible, but there it is. In a way,
JSON is a bit of an optical illusion - it only looks smaller to the
humans.
The ProcessOne guys rock and they've already built some of this,
showing off a Wave client that is an extended version of an XMPP
client written in Tcl/Tk. If anyone from ProcessOne is out there,
please join in the conversation here.
Cheers,
- Bill
On Oct 1, 7:03 pm, elliottcable <google....@elliottcable.com> wrote:
Earlier Peter claimed that JSON isn't extensible, but that is simply
not truthful. If you define extensibility as having a warm fuzzy w3c
document to tell you how to namespace things, well sure, JSON doesn't
have any set rules or expectations there, but there is absolutely
nothing to stop you from specifying your own extensibility rules in
your particular use of JSON. You can name properties along the lines
of 'com.creativepony.myThing' for a pretty good level of ownership,
and require clients silently ignore unknown property names, as most
already do. There are other techniques as well, but that is my
favourite. If you want to up the performance in javascript, switch out
the dots for underscores, to save yourself from using the slightly
slower ["blah"] object property lookup operator.
That aside, I'm going against my usual reaction to all sights of XML
as Data Format and supporting XMPP as the client protocol. It makes
sense to keep everything as consistent as possible, share as much code
as we can. By making use of XMPP as the client protocol, we can cut
down on the amount of docs we need, as well as the volume of code
needed in a compliant wave server. XML kind of sucks as a data format,
but we're reasonably used to it now (we put up with the DOM when
building the UI, so it's not that terrible to do so on the protocol
end as well). Wave servers would also be able to implement their own
JSON, RPC, or whatever protocols for talking to their own clients if
they wish, or could just translate the XML DOM in to a quick and dirty
JSON version for a small performance boost.
—
Jenna Fox
On Oct 2, 9:48 am, elliottcable <google....@elliottcable.com> wrote:
> It looks like some people misunderstood the point…
> On Oct 1, 6:35 am, James Jones <ja...@freedomnet.co.nz> wrote:
> > why not just keep using XMMP?
> Wave is *not* using XMPP right now for the C/S protocol. Only for
> federation. The point of this discussion is to decide upon a C/S
> protocol that doesn’t suck; I am personally lobbying for XMPP to be
> said protocol.
> On Oct 1, 6:42 am, Peter Saint-Andre <stpe...@stpeter.im> wrote:
> > On 10/1/09 2:43 AM, elliottcable wrote:
> > > I personally am interested in seeing XMPP become not only the
> > > foundation of
> > > the federation protocol, but of the C/S protocol as well. When I first
> > > heard
> > > about Wave, before getting into the Sandbox, I was very excited; it
> > > sounded
> > > like a great idea, based on great tools (XMPP!). Unfortunately, I was
> > > extremely disappointed to find that XMPP really has nothing whatsoever
> > > to do
> > > with Wave, and I’d like to see that remedied.
> > I'd be happy to help with an XMPP binding.
> An XMPP ‘binding’? No, we don’t want to bind the existing RPC/protobuf
> psuedo–protocol to XMPP, we want to replace it. Google has, multiple
> times and places, said it’s very open to yanking out that hacky crap
> and replacing it with a protocol that the community can agree on. So,
> all that’s left is for us to agree on one, and tell google ‘implement
> this.’
> On Oct 1, 6:42 am, Peter Saint-Andre <stpe...@stpeter.im> wrote:
> > On 10/1/09 2:43 AM, elliottcable wrote:
> > > Really, though, any sensible protocol that we can agree on would be
> > > great.
> > > Another option is possibly something involving JSON; that’d make
> > > JavaScript
> > > heavy–clients ridiculously easy to write for the web.
> > JSON is not extensible. IMHO that's going to make it difficult to build
> > anything interesting.
> I disagree about JSON not being extensible, but it’s not really my
> ‘favourite horse’ for this race, anyway.
> On Oct 1, 9:41 am, danbirlem <dman....@gmail.com> wrote:
> > XMPP seems like it should have been adopted and pushed for, cradle to
> > grave when the words 'real time collaboration' were mentioned.
> > However, I would not put it past that this protocol will rival XMPP in
> > terms of flexibility.
> > Just my two cents...
> What do you mean by ‘this protocol’? The RPC/protobufs C/S protocol
> currently in use? To even call that a protocol is kind of laughable.
> Read above, it’s largely irrelevant as long as ‘we the people’ can
> agree on a real protocol in a timely manner, so Google doesn’t change
> their mind about being willing to use whatever we agree on.
> On Oct 1, 10:27 am, Peter Ferne <peter.fe...@gmail.com> wrote:
> > On 1 Oct 2009, at 09:43, elliottcable wrote:
> > > I personally am interested in seeing XMPP become not only the
> > > foundation of the federation protocol, but of the C/S protocol as
> > > well.
> > Absolutely. It looks as if ProcessOne have already done some work
> > towards this.http://tr.im/p1waveIsanybody from there on this list?
> > It would be great if they were happy to share that work publicly.
> > --
> > petef
> Hey, that looks pretty relevant. Maybe I’ll try to email some of their
> guys with a Google Groups link to this thread later today.
> (Also, damn you, Google Groups, for automatically wrapping my text!
> I’m so used to hard–wrapping everything I type at 78 characters…
> sorry, to everybody else, for producing an original message unreadable
> on Google Groups >_<)
On 2 oct, 02:45, bedney <bed...@technicalpursuit.com> wrote:
> The ProcessOne guys rock and they've already built some of this,
> showing off a Wave client that is an extended version of an XMPP
> client written in Tcl/Tk. If anyone from ProcessOne is out there,
> please join in the conversation here.
Sorry I missed this thread.
I will catch up on this and would be glad to collaborate :)
To add another item on the list of advantages to using XMPP: it may
draw in people who have already worked on xmpp implementations, as the
c/s protocol would be an "extension" to XMPP. (Putting extension in
quotes, so as not to imply how it might end up.)
> On Oct 1, 11:38 pm, Mickaël Rémond <mrem...@gmail.com> wrote: >> Sorry I missed this thread. >> I will catch up on this and would be glad to collaborate :)
I'm interested in getting that - I would like to see how Wave plays
with my development team.
JSON vs XMPP...XMPP keeps coming out on top for me - the collaboration
and usability of it (plus, I have a background developing with it, so
I might be a little more bias haha) just puts the nail in coffin for
me.
If you want to write a client/server protocol, it helps to have a client
to test against. A small group of us started developing an emacs client
for Wave, right now just using a simple lisp-like REPL to enable us to
get a UI ready on the emacs side quickly. The eventual goal is to use a
real client/server protocol. Discussing with a few colleagues, some
liked XMPP, some preferred JSON. I don't have any strong preferences.
If we use XMPP, it's like the federation protocol. If we use JSON, it's
more like the actual protocol the web client uses. I was leaning to use
JSON, personally, but both are workable.
> With the opening of the actual Google Wave preview today, I think it’s
> high
> time we re–opened the topic of the client–server (C/S) protocol.
> As the FAQ for this group says:
> > What is the client-server protocol?
> > -------------------------------------------------
> > The focus of our open source and protocol work at this point is on
> > the federation protocol, which is critical for getting inter-operable
> > server implementations, that is, for allowing many other people to
> > build Wave servers and have them interop with each other and with the
> > Google Wave server. We have definitely heard the requests for defining
> > a client-server protocol, but at this time the team doesn't have the
> > time to put into such an effort.
> > If you are interested in working on the client-server protocol we
> > are happy to host that discussion here, and the client-server protocol
> > as implemented in the open source server would be a fine place to
> > start.
> Let’s get that discussion started, shall we? Federation is great, a
> user
> preview that dumb randoms can press pretty HTML buttons on is great,
> but Wave
> (the concept) is really quite useless until somebody can install a
> Wave client
> and talk to their Wave server of choice in that client, and read waves
> from
> other Wave users writing things in their own clients through their own
> servers. None of that is possible until we (client developers) can get
> started
> writing our client libraries, GUI clients, web clients, and
> programmatic
> clients… and none of *those* are possible until we have a guarantee
> that our
> hard work and sweaty hours of coding will produce a product that will
> be
> useful on more than just Google’s Wave server.
> No offence to the Google Wave team (everything else they’ve come up
> with is
> pretty great), but the RPC/protobufs solution is… very much a non–
> solution,
> really. What, exactly, do we all want to see in this protocol?
> I personally am interested in seeing XMPP become not only the
> foundation of
> the federation protocol, but of the C/S protocol as well. When I first
> heard
> about Wave, before getting into the Sandbox, I was very excited; it
> sounded
> like a great idea, based on great tools (XMPP!). Unfortunately, I was
> extremely disappointed to find that XMPP really has nothing whatsoever
> to do
> with Wave, and I’d like to see that remedied.
> Really, though, any sensible protocol that we can agree on would be
> great.
> Another option is possibly something involving JSON; that’d make
> JavaScript
> heavy–clients ridiculously easy to write for the web.
> Please, weigh in, and let’s get this hump over with!
I’m personally intending to write at least three separate Wave clients
(Mac, iPhone, and CLI… Cocoa/Objective-C, Cocoa Touch, and Ruby
respectively); so there’s certainly a client–developer voice in here.
I see absolutely no reason to “start writing a client” without a C/S
protocol, though, as you can’t really write anything at all other than
some boilerplate code. Hence why I’m pushing so hard for a C/S
protocol.
On Oct 3, 2:35 pm, Andrew Hyatt <ahy...@google.com> wrote:
> If you want to write a client/server protocol, it helps to have a client
> to test against. A small group of us started developing an emacs client
> for Wave, right now just using a simple lisp-like REPL to enable us to
> get a UI ready on the emacs side quickly. The eventual goal is to use a
> real client/server protocol. Discussing with a few colleagues, some
> liked XMPP, some preferred JSON. I don't have any strong preferences.
> If we use XMPP, it's like the federation protocol. If we use JSON, it's
> more like the actual protocol the web client uses. I was leaning to use
> JSON, personally, but both are workable.
> On Thu, Oct 1, 2009 at 4:43 AM, elliottcable <google....@elliottcable.com>wrote:
> > With the opening of the actual Google Wave preview today, I think it’s
> > high
> > time we re–opened the topic of the client–server (C/S) protocol.
> > As the FAQ for this group says:
> > > What is the client-server protocol?
> > > -------------------------------------------------
> > > The focus of our open source and protocol work at this point is on
> > > the federation protocol, which is critical for getting inter-operable
> > > server implementations, that is, for allowing many other people to
> > > build Wave servers and have them interop with each other and with the
> > > Google Wave server. We have definitely heard the requests for defining
> > > a client-server protocol, but at this time the team doesn't have the
> > > time to put into such an effort.
> > > If you are interested in working on the client-server protocol we
> > > are happy to host that discussion here, and the client-server protocol
> > > as implemented in the open source server would be a fine place to
> > > start.
> > Let’s get that discussion started, shall we? Federation is great, a
> > user
> > preview that dumb randoms can press pretty HTML buttons on is great,
> > but Wave
> > (the concept) is really quite useless until somebody can install a
> > Wave client
> > and talk to their Wave server of choice in that client, and read waves
> > from
> > other Wave users writing things in their own clients through their own
> > servers. None of that is possible until we (client developers) can get
> > started
> > writing our client libraries, GUI clients, web clients, and
> > programmatic
> > clients… and none of *those* are possible until we have a guarantee
> > that our
> > hard work and sweaty hours of coding will produce a product that will
> > be
> > useful on more than just Google’s Wave server.
> > No offence to the Google Wave team (everything else they’ve come up
> > with is
> > pretty great), but the RPC/protobufs solution is… very much a non–
> > solution,
> > really. What, exactly, do we all want to see in this protocol?
> > I personally am interested in seeing XMPP become not only the
> > foundation of
> > the federation protocol, but of the C/S protocol as well. When I first
> > heard
> > about Wave, before getting into the Sandbox, I was very excited; it
> > sounded
> > like a great idea, based on great tools (XMPP!). Unfortunately, I was
> > extremely disappointed to find that XMPP really has nothing whatsoever
> > to do
> > with Wave, and I’d like to see that remedied.
> > Really, though, any sensible protocol that we can agree on would be
> > great.
> > Another option is possibly something involving JSON; that’d make
> > JavaScript
> > heavy–clients ridiculously easy to write for the web.
> > Please, weigh in, and let’s get this hump over with!
I should point out, for anybody following this, that the discussion
has mostly moved to Wave… if you don’t have a Wave account, get in
touch with me, and I can bring your voice into the discussion there.
On Oct 3, 2:35 pm, Andrew Hyatt <ahy...@google.com> wrote:
> If you want to write a client/server protocol, it helps to have a client
> to test against. A small group of us started developing an emacs client
> for Wave, right now just using a simple lisp-like REPL to enable us to
> get a UI ready on the emacs side quickly. The eventual goal is to use a
> real client/server protocol. Discussing with a few colleagues, some
> liked XMPP, some preferred JSON. I don't have any strong preferences.
> If we use XMPP, it's like the federation protocol. If we use JSON, it's
> more like the actual protocol the web client uses. I was leaning to use
> JSON, personally, but both are workable.
> On Thu, Oct 1, 2009 at 4:43 AM, elliottcable <google....@elliottcable.com>wrote:
> > With the opening of the actual Google Wave preview today, I think it’s
> > high
> > time we re–opened the topic of the client–server (C/S) protocol.
> > As the FAQ for this group says:
> > > What is the client-server protocol?
> > > -------------------------------------------------
> > > The focus of our open source and protocol work at this point is on
> > > the federation protocol, which is critical for getting inter-operable
> > > server implementations, that is, for allowing many other people to
> > > build Wave servers and have them interop with each other and with the
> > > Google Wave server. We have definitely heard the requests for defining
> > > a client-server protocol, but at this time the team doesn't have the
> > > time to put into such an effort.
> > > If you are interested in working on the client-server protocol we
> > > are happy to host that discussion here, and the client-server protocol
> > > as implemented in the open source server would be a fine place to
> > > start.
> > Let’s get that discussion started, shall we? Federation is great, a
> > user
> > preview that dumb randoms can press pretty HTML buttons on is great,
> > but Wave
> > (the concept) is really quite useless until somebody can install a
> > Wave client
> > and talk to their Wave server of choice in that client, and read waves
> > from
> > other Wave users writing things in their own clients through their own
> > servers. None of that is possible until we (client developers) can get
> > started
> > writing our client libraries, GUI clients, web clients, and
> > programmatic
> > clients… and none of *those* are possible until we have a guarantee
> > that our
> > hard work and sweaty hours of coding will produce a product that will
> > be
> > useful on more than just Google’s Wave server.
> > No offence to the Google Wave team (everything else they’ve come up
> > with is
> > pretty great), but the RPC/protobufs solution is… very much a non–
> > solution,
> > really. What, exactly, do we all want to see in this protocol?
> > I personally am interested in seeing XMPP become not only the
> > foundation of
> > the federation protocol, but of the C/S protocol as well. When I first
> > heard
> > about Wave, before getting into the Sandbox, I was very excited; it
> > sounded
> > like a great idea, based on great tools (XMPP!). Unfortunately, I was
> > extremely disappointed to find that XMPP really has nothing whatsoever
> > to do
> > with Wave, and I’d like to see that remedied.
> > Really, though, any sensible protocol that we can agree on would be
> > great.
> > Another option is possibly something involving JSON; that’d make
> > JavaScript
> > heavy–clients ridiculously easy to write for the web.
> > Please, weigh in, and let’s get this hump over with!
> I should point out, for anybody following this, that the discussion > has mostly moved to Wave… if you don’t have a Wave account, get in > touch with me, and I can bring your voice into the discussion there.
I'm still waiting for my invite to be processed by Google so I'd appreciate it if you could post a periodic update here.
On Mon, Oct 5, 2009 at 2:24 AM, Tad Glines <tad.gli...@gmail.com> wrote:
> On Sat, Oct 3, 2009 at 7:11 PM, elliottcable > <google....@elliottcable.com> wrote:
> > I should point out, for anybody following this, that the discussion > > has mostly moved to Wave… if you don’t have a Wave account, get in > > touch with me, and I can bring your voice into the discussion there.
> I'm still waiting for my invite to be processed by Google so I'd > appreciate it if you could post a periodic update here.
> I agree, I think that the discussion would be best served by having it in a
widely accessible forum, such as this.
From what I could see the discussion wave regarding this hasn't come very far. There seems to be interest in settling on an extension to XMPP, but there still lacks any work on outlining what such a protocol should encompass. This would probably be a good start.
Maybe, as a 'starter straw man', Mickaël Rémond can outline the work
they've done in running XMPP 'all the way out to the client' at
ProcessOne (the makers of the kick-a** Erlang XMPP server ejabberd).
As one can see from another thread around here, the 0.3 version of the
server<->server XMPP protocol is being hashed out (with no less than
core XMPP team folks like Peter St. Andre contributing). The big
question I have is around this question of protobufs (I keep typing
'protobugs' - a Freudian slip? ;-) ) embedded in the XML. This imposes
an external dependency on what is otherwise a 'pure XML' format. I'm
sure Mickaël can say more about this. They are showing an update to
ejabberd that is obviously doing protobufs in Erlang. Their client is
written in Tcl/Tk so he can shed more light on whether they're
actually doing OT in the client (which would imply a protobufs
implementation written in Tcl) or, like the FedOne client and server,
the client is very 'dumb' (not doing OT) and just passing character
data back to the server.
One very intriguing thing that you'll find if you watch the ProcessOne
video is the usage of the XMPP 'discovery mechanism' ('disco') to
discover waves.
Cheers,
- Bill
On Oct 4, 2:48 pm, Joe Developer <joe.d.develo...@gmail.com> wrote:
> On Mon, Oct 5, 2009 at 2:24 AM, Tad Glines <tad.gli...@gmail.com> wrote:
> > On Sat, Oct 3, 2009 at 7:11 PM, elliottcable
> > <google....@elliottcable.com> wrote:
> > > I should point out, for anybody following this, that the discussion
> > > has mostly moved to Wave… if you don’t have a Wave account, get in
> > > touch with me, and I can bring your voice into the discussion there.
> > I'm still waiting for my invite to be processed by Google so I'd
> > appreciate it if you could post a periodic update here.
> > I agree, I think that the discussion would be best served by having it in a
> widely accessible forum, such as this.
> From what I could see the discussion wave regarding this hasn't come very
> far.
> There seems to be interest in settling on an extension to XMPP, but there
> still lacks any work on outlining what such a protocol should encompass.
> This would probably be a good start.
<google....@elliottcable.com> wrote:
> I should point out, for anybody following this, that the discussion
> has mostly moved to Wave… if you don’t have a Wave account, get in
> touch with me, and I can bring your voice into the discussion there.
I have a wave account, but when I try to open the wave link mentioned
earlier, I get "You are not a participant of this wave". Do I need to
add myself to some group or something like that?
I may not have much to contribute to the protocol itself, but I
certainly would like to at least keep an eye on the discussion...
Btw, for those of you don't have a wave account, I have *a few*
invites that I can spare. Please don't post your requests here -
contact me in private instead. I think you should be able to get my
email from my profile details if you're not a bot.
On Oct 2, 2:03 am, elliottcable <google....@elliottcable.com> wrote:
If possible i would love to get an account to participate in this discussion
in a wave, haha i think it would be so much simpler to discuss all this in
realtime :)
On Mon, Oct 5, 2009 at 10:15 AM, Michael K <mk.mat...@gmail.com> wrote:
> On Sat, Oct 3, 2009 at 7:11 PM, elliottcable
> <google....@elliottcable.com> wrote:
> > I should point out, for anybody following this, that the discussion
> > has mostly moved to Wave… if you don’t have a Wave account, get in
> > touch with me, and I can bring your voice into the discussion there.
> I have a wave account, but when I try to open the wave link mentioned
> earlier, I get "You are not a participant of this wave". Do I need to
> add myself to some group or something like that?
> I may not have much to contribute to the protocol itself, but I
> certainly would like to at least keep an eye on the discussion...
> Btw, for those of you don't have a wave account, I have *a few*
> invites that I can spare. Please don't post your requests here -
> contact me in private instead. I think you should be able to get my
> email from my profile details if you're not a bot.
> On Oct 2, 2:03 am, elliottcable <google....@elliottcable.com> wrote:
> > Oh, worth noting: I cross–posted a wave on this subject; if you’re in
> > the preview (not the Sandbox!) click:
> If possible i would love to get an account to participate in this
> discussion in a wave, haha i think it would be so much simpler to discuss
> all this in realtime :)
> On Mon, Oct 5, 2009 at 10:15 AM, Michael K <mk.mat...@gmail.com> wrote:
>> On Sat, Oct 3, 2009 at 7:11 PM, elliottcable
>> <google....@elliottcable.com> wrote:
>> > I should point out, for anybody following this, that the discussion
>> > has mostly moved to Wave… if you don’t have a Wave account, get in
>> > touch with me, and I can bring your voice into the discussion there.
>> I have a wave account, but when I try to open the wave link mentioned
>> earlier, I get "You are not a participant of this wave". Do I need to
>> add myself to some group or something like that?
>> I may not have much to contribute to the protocol itself, but I
>> certainly would like to at least keep an eye on the discussion...
>> Btw, for those of you don't have a wave account, I have *a few*
>> invites that I can spare. Please don't post your requests here -
>> contact me in private instead. I think you should be able to get my
>> email from my profile details if you're not a bot.
>> On Oct 2, 2:03 am, elliottcable <google....@elliottcable.com> wrote:
>> > Oh, worth noting: I cross–posted a wave on this subject; if you’re in
>> > the preview (not the Sandbox!) click:
