Today's Topic Summary
Group: http://groups.google.com/group/wave-protocol/topics
Documents and Schemas [1 Update]
Posts Focusing on FedOne Design [2 Updates]
Access Control white-paper questions [1 Update]
On the purpose of commit-notice [3 Updates]
Draft Specifications and Whitepapers [1 Update]
Skip op [1 Update]
Timeline for opening federation in production? [1 Update]
Topic: Documents and Schemas
Tad Glines <[email protected]> Feb 16 08:49PM -0800 ^
There seems to be three possible ways to enforce a schema in wave:
1. Play nice: Clients are expected to play nice together.
2. Server enforced: The server (specifically the federation host)
enforces the schema.
3. Agent enforced: Extend the existing agent interface so that the
server can pass an transformed but unapplied delta to a "schema" agent
for verification.
The play nice has fundamental problems with trust and consistency. All
it takes is one rogue client (accidental or intentional) and many a
wave go "shiny".
The server enforced model can work, but there's a question of how the
server would know what schema to enforce on which documents (or set of
documents). For some common schemas a fixed namespace to schema
mapping might work. But for less well know clients, this could become
problematic. Defining a schema in a wave might work, but only if there
was a way to assign that "schema" wave to the "content" wave and
ensure that the "schema" wave was propagated along with the "content"
wave. The existing wave mechanisms don't support this.
The agent approach has the potential to make things a little simpler.
We already have the concept of agents that perform actions within a
wave (spelly for example). And some robots being developed are
performing content control type actions. And users are becoming
familiar with the idea of adding a robot/agent to their wave to
enhance it. So perhaps we can extend this "plug-able capability"
concept to include the addition of content enforcement capabilities to
agents. So, for example, when I create a "conversation" wave the
"conversation" agent is added as a non-removable participant to the
wave and acts as the schema enforcement agent. All deltas would be
passed to the agent prior to being applied. The agent would have the
option of requesting additional content from the wave before
approving/disproving the delta. This might also work with robots, but
has the potential to cause a serious bottleneck if the robot isn't
implemented/provisioned appropriately.
-Tad
Topic: Posts Focusing on FedOne Design
antwatkins <[email protected]> Feb 16 09:59AM -0800 ^
Hello All,
I have posted part 4 in the FedOne Series. This is more of a
reference that gives you the location in code that corresponds to the
receipt and execution of messages received in XMPP. If you are
curious what section of code handles the Wavelet update for example,
you will see where it is read in as an XMPP packet and stripped and
also where the WaveServer processes the resulting information.
Post Here: http://www.angleofsight.com/2010/02/google-wave-federation-part-4/
R,
Anthony
Anthony Baxter <[email protected]> Feb 17 01:43PM +1100 ^
I'd just like to say that these are very nice and very useful posts,
and I'd like to encourage you to write more of them!
Thanks very much for the work you've put into them.
Anthony
--
Anthony Baxter, [email protected]
Topic: Access Control white-paper questions
Tad Glines <[email protected]> Feb 16 11:45AM -0800 ^
Has anyone at Google read this? The first part is mainly a question of
clarification, but the rest covers what appears to be a serious
chick-and-egg problem.
-Tad
Topic: On the purpose of commit-notice
Torben Weis <[email protected]> Feb 16 01:34PM +0100 ^
Hi,
during my wave-server-hacking-quest I started to wonder what the real
purpose of commit-notice is. My Wireshark experiments showed that I
can get
a wavelet-update in one XMPP stanza and the commit-notice in the
next one
(without any reconnects in between). Thus, the wavelet-update I
received is
uncommitted for some short time?
Here is an excerpt of the XMPP data:
<message type="normal" from="wave.wave1.vs.uni-due.de" id="5571-2"
to="
wave.wave2.vs.uni-due.de">
<request xmlns="urn:xmpp:receipts"/>
<event xmlns="http://jabber.org/protocol/pubsub#event";>
<items>
<item><wavelet-update xmlns="
http://waveprotocol.org/protocol/0.2/waveserver"; wavelet-name="wave://
wave1.vs.uni-due.de/w+286932502/conv+root
"><applied-delta><![CDATA[CvkBCk0KGAgIEhQnq6X...tPLk5yQ=]]></applied-
delta></wavelet-update>
</item>
</items>
</event>
</message>
<message type="normal" from="wave.wave1.vs.uni-due.de" id="9727-3"
to="
wave.wave2.vs.uni-due.de">
<request xmlns="urn:xmpp:receipts"/>
<event xmlns="http://jabber.org/protocol/pubsub#event";>
<items><item><wavelet-update xmlns="
http://waveprotocol.org/protocol/0.2/waveserver"; wavelet-name="wave://
wave1.vs.uni-due.de/w+286932502/conv+root">
<commit-notice version="9"
history-hash="D40bHaCz3fmoyKumEnWorK8vQVA="/></wavelet-update>
</item>
</items>
</event>
</message>
1) If the wavelet update is really uncommitted for some time:
Handing out data that is not yet committed seems like asking for
trouble.
The only reason for doing so is IMHO to gain speed (i.e. no need to
synchronize with disk IO) and hope that it does not come back to
bite us.
What is a remote wave server expected to do with uncommitted data?
a) It is holding data back until it is committed, then sends data to
its
clients -> most of the speed gain is gone -> the performance gain is
perhaps
not worth the effort
b) It is sending uncommitted data to the client. What happens if no
commit
notice appears? How long should the server wait? If no commit notice
arrives, what to do? The clients have already consumed uncommitted
data ->
the wave blows up in front of the users
2) If my reading is wrong and the update is committed before the
update is
sent:
Then commit notice is only kind of a reminder that some wavelet has
reached
a certain version number. In this case the spec should state that all
wavelet updates sent are committed. Furthermore, the above commit
notice
could be omitted.
What is the intended purpose of commit-notice?
Cheers
Torben
antwatkins <[email protected]> Feb 16 09:52AM -0800 ^
Torben,
I'm going to point out where I think this occurs and then piggy-back
on your question.
If you go to fedone.waveserver.WaveServerImpl.submitDelta() you'll see
the comment:
//Broadcast results to the remote servers, but make sure they all have
our signatures.
Following this comment a call is made to host.waveletDeltaUpdate()
with a listener defined for the callback. After this is done, you
see:
// TODO: if persistence is added, don't send commit notice
host.waveletCommitUpdate(waveletName, resultingVersion,
new WaveletFederationListener.WaveletUpdateCallback()
{
@Override
public void onSuccess() {
}
@Override
public void onFailure(String errorMessage) {
LOG.warning("outgoing waveletCommitUpdate failure:
" + errorMessage);
}
});
I believe you get the first response from the listener after the
update is successful and the second commit notice from the code
snippet above. The message (if persistence was added) is indeed
committed when you get the first notice in response to the
waveletUpdate.
The path this occurs is fedone.waveserver.WaveServerImpl.submitDelta()
which has the following code:
synchronized (wc) {
submitResult = wc.submitRequest(waveletName, delta);
submitRequest() is then handled by
fedone.waveserver.LocalWaveletContainerImpl.submitRequest() which
calls
fedone.waveserver.LocalWaveletContainerImpl.transformAndApplyLocalDelta(
)
which has the following code:
DeltaApplicationResult applicationResult =
commitAppliedDelta(appliedDelta,
new WaveletDelta(deltaAndVersion.first.getAuthor(),
transformedOps));
This calls
fedone.waveserver.WaveletContainerImpl.commitAppliedDelta(), which
commits the delta to the wavelet container and returns the result.
Theoretically if persistence was added, it would occur here and return
the result all the way back up the chain to
fedone.waveserver.WaveServerImpl.submitDelta() (Google, please advise
if I am wrong).
So my question isn't much different than Torben's. Why are we sending
a commit-notice and what does that have to do with the fact that we
don't have persistence yet since the comment in
fedone.waveserver.WaveServerImpl.submitDelta() says:
// TODO: if persistence is added, don't send commit notice
Thanks,
Anthony
Torben Weis <[email protected]> Feb 16 07:01PM +0100 ^
Hi,
thanks for the code walk. This helps explaining which part of the
code is
doing this. Let's hope that Google tells us why :-)
> don't have persistence yet since the comment in
> fedone.waveserver.WaveServerImpl.submitDelta() says:
> // TODO: if persistence is added, don't send commit notice
Perhaps the meaning of the comment is to send the commit notice
later (i.e.
after data has been persisted)? Currently the commit notice is sent
automatically without waiting for any commit (just guessing).
Torben
Topic: Draft Specifications and Whitepapers
Joe Gregorio <[email protected]> Feb 16 11:31AM -0500 ^
The source for the draft specifications and whitepapers have now
been moved into the mercurial repository.
http://code.google.com/p/wave-protocol/source/browse/#hg/spec
http://code.google.com/p/wave-protocol/source/browse/#hg/whitepapers
The source for both the specs and whitepapers is
ReStructuredText, and you can find the documentation
for that here: http://docutils.sourceforge.net/rst.html
The use of ReStructuredText makes for human readable diffs, making
code reviews
of changes to the specs and whitepapers easier. For example:
http://codereview.waveprotocol.org/37001/diff/1/3
(Besides, if making humans edit XML is sadistic, how bad is it
to make a human review diffs of XML documents?)
If you have changes to the whitepapers or draft specifications please
follow the same process used for submitting changes to the code, which
includes signing a contributor agreement.
http://code.google.com/p/wave-protocol/wiki/SubmittingCode
Thanks,
-joe
--
Joe Gregorio
Developer Relations, Google Wave
Topic: Skip op
Joe Gregorio <[email protected]> Feb 16 11:22AM -0500 ^
> comments. In some places FedOne behavior is not in sync with the
spec and I
> am not sure whose fault this is, i.e. spec or FedOne. I hope you
find the
> patch or parts of it useful.
Thank you for that! I had recently updated how the specifications and
whitepapers
are handled but forgot to send a general note to the list. I will do
that now.
Thanks,
-joe
Topic: Timeline for opening federation in production?
Jason Kolb <[email protected]> Feb 16 07:14AM -0800 ^
I've been looking for an answer to this but can't find anything, are
there any timelines out there at all for when federation will be
opened up for the production environment? Even something as vague as
this year, next year, etc? I guess I had expected to hear more about
this than I have at this point, and I think it's very important--
especially if Google hopes to have a third-party ecosystem living
around this protocol/product.
--
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
.
