I believe WAIB should be split into modules. If we adopted Maven as
build tool it would really make things a lot simpler.
We should have pure api modules and then default impl packages. This
would allow anyone to contribute sample client, server, etc
implementations which could then be integrated into WAIB.
On 11-04-2011 14:07, Thomas Wrobel wrote:
On of the current things with WiaB seems to be that the server and client are
all rolled in to one. For people wanting desktop clients, mobile clients, etc,
I think it is critical to have a well defined protocol for the client and
server to work together.
~Michael
Couldn't possibly agree more with that!
It would be nice if client development could be done relatively
independently from server development, I think both would proceed
faster if they wernt so tied together.
-Thomas
On Apr 9, 2011, at 3:32 PM, Thomas Wrobel wrote:
Remember there is strong pro XMPP voices here too;
http://www.process-one.net/en/blogs/article/xwave_a_tribute_to_google_wave_team/
I'm not sure who is right on a technical sense, but there is working
xmpp based federations out there, are their any based on http?
Regarding the c/s protocol - it makes somewhat sense anyway if it was
more or less the same as the server/server one, seeing as they both
basically have to exchange the same information to keep the document
in sync.
As I suggested on the recent poll,however, I think separating out the
wiab webclient and using a lib for c/s protocol would help a lot. That
way , even if different choices are made for the protocol later on,
its just the lib that has to be changed. People could thus make
clients with the protocol itself abstracted away.
~~~~~~
Reviews of anything, by anyone;
www.rateoholic.co.uk
Please try out my new site and give feedback :)
On 10 April 2011 00:13, Michael MacFadden<[email protected]> wrote:
Nelson,
There has been large debate on XMPP in wave. The general complaint is that the
protocol is to verbose. My two cents are that one of the main points of XMPP
was a verbose XML human readable protocol with standard extension mechanisms.
However wave uses protobufs and base64 encodes all the data in the XMPP
stanzas. The data exchanged by wave is not human readable, xml based, or part
of the XMPP standard. That defeats the purpose of using the XMPP standard in
the first place. In my opinion this basically relegates XMPP to just a
delivery envelope, and one that adds on a lot of overhead.
Also XMPP's dependance on long lived TCP connections to maintain the xml stream, there
are difficulties providing services to clients that are frequently disconnected. For
these reasons there is talk of adding a "raw" http transfer mechanism for
federation. Until that is worked out I would hesitate to entertain the idea of injecting
XMPP in to the c/s protocol.
~Michael
On Apr 9, 2011, at 2:51 PM, Nelson Silva wrote:
XMPP over websockets was proposed as a draft
(http://tools.ietf.org/html/draft-moffitt-xmpp-over-websocket-00) and ejabberd
now has a sample module to support it:
http://blog.superfeedr.com/xmpp-over-websockets/
Wouldn't it be great to use XMPP for both C/S and federation ? or is it too
verbose ?
Just wanted to share this with the list.
Regards,
Nelson
