> 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
>>>
>>>
>
>

Reply via email to