Hi Joe,
> I hacked around the bugs and according to my testing you can now chat with
> > WaveSandBox users via QWaveClient.
>
> Congrats!
>
Thanks.
>
> That's a known issue, the <contributor> element is documented as something
> we are going to implement, but it currently isn't implemented.
>
Sure. I just became confused because WaveSandBox crashed instead of
rejecting the delta containing <contributor>.
This leads to an interesting question (at least for me): Who should handle
non-standard elements? Server or client?
The server could detect it and refuse the delta in the first place, but it
puts additional load on the server.
The client could try to tolerate the non-standards elements instead (or go
for a nice "shiny" :-) )
A drawback of server checking is that we need a server update whenever there
is an extension to the conversational model. Most likely a no go.
> > annotation_boundary {
> > end: "user/d/Wlir8vFX"
> > }
> > This stuff is used all over the place and it is not specified anywhere.
>
> The user annotations are described in the conversation model specification:
>
>
> http://wave-protocol.googlecode.com/hg/spec/conversation/convspec.html#anchor29
>
> Uh. This one escaped my attention. Thanks for the hint.
However, is this really required to know where a remote user is currently
typing? QWaveClient can do without (more or less). I check the deltas to
find out where the last change occurred and show the caret there for some
time. The only problem is that I do not know how old a delta is since they
do not carry timestamps in the C/S protocol (but they do on the federation
protocol).
I am a bit skeptical because this puts a lot of additional load on the
server bandwidth and OT capacity while there might be a "cheaper" solution.
However, I agree that there is no other possibility for displaying other
user's text-range-selection.
In general, while implementing federation for the C++ wave server, I become
increasingly worried about performance. Just consider the process of
converting internal data structures of a delta to protobufs (WaveletDelta),
signing these, copying them into another protobuf (SignedWaveletDelta),
encoding it as base64 and then inserting it in XML for XMPP-sending. This is
a lot of copying going on. There are ways of optimizing the implementation
of this process, but this requires a stack that melts protobufs, base64 and
XML. This is heavy lifting, especially for open source projects which prefer
to use solutions that are readily available.
And I did not even start to discuss the additional performance drain caused
by the XMPP server, because FedOne and the C++ server act as XMPP components
only. Building a native XMPP component is way out of scope unfortunately.
Would not it be sufficient if two servers communicate only via TCP/protobufs
and to secure the communication via SSL/TLS? Simple, more efficient, same
set of features. The more I hack on the server-side, the less I am
convinced. XMPP is a nice thing and a very well-established standard. But I
cannot really see the big advantage of using it for wave currently. The only
thing coming to my mind is roster management. But even this does not work
all to well because a user may chat via [email protected] while waving via
[email protected], i.e. one user two JIDs. But which is wave and which is
chat? I need to send iq stanzas to query both servers for wave support. What
to do if both support wave?
I know that I made myself a nice target for the XMPP fans now (duck and
cover), but in the end the critical information is encoded as protobufs
anyway. Wrapping these in expensive layers of XML is not the pure XMPP
solution anyway.
I don't want to offend anyone with my ramblings and I will happily continue
hacking on XMPP-based federation. I just do not get the rational of this
approach currently. Perhaps I simply missed the point so far. So I am hoping
for enlightenment :-)
Greetings
Torben
> Thanks,
> -joe
>
> > Thus, QWaveClient ignores it.
> > Cheers
> > Torben
> > PS: Aldon, thanks for offering your server for the tests.
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Wave Protocol" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> > [email protected]<wave-protocol%[email protected]>
> .
> > For more options, visit this group at
> > http://groups.google.com/group/wave-protocol?hl=en.
> >
>
> --
> Joe Gregorio
> Developer Relations, Google Wave
>
> --
> You received this message because you are subscribed to the Google Groups
> "Wave Protocol" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<wave-protocol%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/wave-protocol?hl=en.
>
>
--
---------------------------
Prof. Torben Weis
Universitaet Duisburg-Essen
[email protected]
--
You received this message because you are subscribed to the Google Groups "Wave
Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.
