blambo / wave-protocol Goto Github PK

I assume 'appleddelta' should read 'applieddelta' :-)

What steps will reproduce the problem?
1. cd wave-protocol
2. ant
3.

What is the expected output? What do you see instead?

It is expected to build without errors.

What version of the product are you using? On what operating system?
Mac OS X 10.5.7

Please provide any additional information below.

Here is the error message -

compile:
    [javac] Compiling 157 source files to /Users/XXX/Desktop/wave-protocol/build/core
    [javac] /Users/XXX/Desktop/wave-
protocol/src/org/waveprotocol/wave/examples/fedone/FlagBinder.java:36: cannot 
access 
org.xmpp.packet.Message
    [javac] bad class file: /Users/XXX/Desktop/wave-
protocol/third_party/runtime/whack/xmpp.jar(org/xmpp/packet/Message.class)
    [javac] class file has wrong version 50.0, should be 49.0
    [javac] Please remove or make sure it appears in the correct subdirectory of the classpath.
    [javac] import org.xmpp.packet.Message;
    [javac]                        ^
    [javac] 1 error

The link to the JupiterWin.ps is broken in the text.

Link in reference is OK.

I'm not sure if this is the right forum, but the Google Wave Federation 
Architecture whitepaper has 
near the beginning of the paper, the following description of a robot:
  "A robot can ben a translation robot or a chess game robot."

It would probably be better to describe what a robot does, and provide those as 
examples of the 
types of robots that can be implemented.  I'm sure those aren't the only two 
choices. :-)

What steps will reproduce the problem?
1. "Fix" testRealSignature/setUp as per the TODOs in 
CertificateManagerImplTest.java
2. Run "ant test"
3. Observe failure

What is the expected output? What do you see instead?

Tests should pass, but they fail.

To be more specific, the relevant tests are testRealSignature and all tests 
which are affected by the enabling of signer info validatation (line 208 at  
version 2e5f1d5c44).

http://code.google.com/p/wave-
protocol/source/browse/test/org/waveprotocol/wave/examples/fedone/waveserve
r/CertificateManagerImplTest.java

The term "WSP" appears in sections 2.1 and 2.2

I can find no mention of what it means in the document.
It probably means "Wave service provider" as mentioned in section 3, but
that is not clear.

Issue 45:   DEBIAN Cannot run program "protoc": java.io.IOException 

Reported by jeroenlinderman, Today (14 hours ago)
I followed the "guide" at http://code.google.com/p/wave-
protocol/wiki/Installation ( The post that is comment by Ilir.Halili, Jul 
31, 2009)


Imperox:/wave-protocol# ant -f build-proto.xml
Buildfile: build-proto.xml

compile:

BUILD FAILED
/wave-protocol/build-proto.xml:8: Execute failed: java.io.IOException: 
Cannot run program "protoc": java.io.IOException: error=2, No such file or 
directory

Total time: 3 seconds
Imperox:/wave-protocol# 

Comment 1 by btkalman, Today (11 hours ago)
It is not necessary to compile the protocol buffer definitions, there are
pre-compiled sources included in the mercurial repository.

(If it is needed, which is *highly* unlikely unless development is being 
done on the
.proto files, the protocol buffer compiler is needed from
http://code.google.com/p/protobuf/). 
Status: WontFix







Comment 2 by jeroenlinderman, Today (2 hours ago)
Allright, thank you for the information. I will skip this part.

Now the following problem:

Imperox:/wave-protocol# ./run-server.sh 
Failed to load Main-Class manifest attribute from dist/fedone-server-
0.2.jar

Imperox:/wave-protocol# java -jar fedone-0.2.jar
Failed to load Main-Class manifest attribute from fedone-0.2.jar

I think i have to set JAVA_HOME, but i cant find the right path...?

http://www.waveprotocol.org/whitepapers/access-control
Storing and exchanging access edges
Authorized access edge

1. The namespace policer for that namespace will not allow edits that are
not authorized.

"policy" instead of "policer". this phrase not good building (duplicate
namespace). may be:

The policy for that namespace will not allow edits that are not authorized.

2. The wave provider of the account maintains this access wave by copying
all the relevant and authorized access edges it encounters while indexing
its own and its federated wave providers' waves.

"its federated wave providers' waves" shown as blue. may be it has broken
link to draft protocol?

3. Authorizing an operation
last phrase is not clear for good understanding:
"In this case the access wave would access edges that are no longer valid."

What steps will reproduce the problem?
1. Install java 6
2. Download fedone-scripts and fedone-server 1.2
3. Configure run-config.sh to set hostname and xmpp-server port
4. Start xmpp-server (ejabberd)
5. Start fedone-server: 
/usr/lib/jvm/java-6-sun/jre/bin/java -jar fedone-server-0.2.jar
--client_frontend_hostname=localhost --client_frontend_port=9876
--xmpp_component_name=wave --xmpp_server_hostname=myhost.com
--xmpp_server_ip=myhost.com --xmpp_server_port=8888 --xmpp_server_secret
1nDisp0s3d --xmpp_server_ping= --certificate_private_key=myhost.com.key
--certificate_files=myhost.com.cert --certificate_domain=myhost.com
--waveserver_disable_verification=true
--waveserver_disable_signer_verification=true

LOG:
<warnings about signature verification disabled>
INFO: Starting client frontend on host: localhost port: 9876
couldn't connect to XMPP server:org.xmpp.component.ComponentException:
org.xmlpull.v1.XmlPullParserException: caused by:
org.xmlpull.v1.XmlPullParserException: resource not found:
/META-INF/services/org.xmlpull.v1.XmlPullParserFactory make sure that
parser implementing XmlPull API is available
Oct 5, 2009 11:42:29 AM org.waveprotocol.wave.examples.fedone.ServerMain run
INFO: Starting server
...
And then quiet.


What is the expected output? What do you see instead?
Expected: Running server

What version of the product are you using? On what operating system?
fedone-server-0.2, ubuntu 8.10

Please provide any additional information below.

A get query for disco#items returns a result for disco#info instead of
disco#items. XEP-0030 requires a consistent reply.

It would be useful if the server responded to an items query with itself as
a single item as this then allows direct communication with a server
without the need to run as a component name (although the org.xmpp library
seems to work against this by assuming all components want to be named
"<component>.<server domain>"). This doesn't appear to be defined in the
draft protocol spec; there's barely any reference to how service discovery
should work.

Example in 3.3.4.6 uses address-path but is referenced as
address-access-path in 3.3.4.4 and Appendix A

XEP-0198 looks like a good fit for our acking model. Barring anything anyone 
else sees, we should 
probably just use it.

Please add the wave server installation and certificate generation steps 
for MS-Windows environment. Also please add the required batch fiels with 
the build.

Suggestion:
An annotation should be a "key wavelet-name" pair, instead of "key value" 
pair.


Background:
Soren Lassen wrote that "If you want an annotation with a complex 
structured value you have two options, either encode the value in a string 
(e.g., using JSON) or put the actual value in a data document in the 
wavelet and let the annotation value be the document id. The latter allows 
you to represent the structured value in XML and it can be edited 
concurrently as operations on the data document are subjected to 
operational transformation."
(http://groups.google.com/group/wave-
protocol/browse_thread/thread/e1f7513ec8acbc45)

And note that in order to use an access control or concurrent editting, you 
have to use a new wavelet.

Note too that "key wavelet-name"-pair annotaions do not impair any of the 
abilities that "key value"-pair annotations have.



Reasons of this suggestion:

1. You cannot identify what is the actual data in "key value"-pair 
annotations.

Since "key value"-pair annotations can contain data itself or wavelet-id 
(you may call it an 'annotation link') that indicates where the actual data 
is, only the creator of the annotation knows what is the actual data.
For example, consider that there is an annotaion which value is "wavelet-
id=111". Then, what is the actual data? Is "wavelet-id=111" ITSELF data? Or 
is the actual data contained in the wavelet whose id is 111? There is no 
common way to identify it.

This leads to another problem.


2. Users cannot edit annotations in "key value"-pair annotations, whereas 
users can edit them in "key wavelet-name"-pair annotaions.

Mainly, robots use annotations. But there should not be any difference in 
abilities in users and robots. But as stated in Reason 1, you cannot know 
what is the actual data. Therefore, you cannot edit annotations that other 
robots created. In other words, a client application cannot create a common 
way for users to edit annotations. But in "key wavelet-name"-pair 
annotaions, a client application can easily show what the data is and 
easily be editted, since data too is just a document in a wavelet.


3. "Key wavelet-name"-pair annotaions provide a consistent way for creating 
annotations.

Even though data itself is the same, if you want an access control or 
concurrent editting, you have to make a new wavelet. So depending on what 
features you want to use, there may be a difference in the way to create an 
annotation. This is not desirable. Since a wavelet has full features that a 
wave has, "key wavelet-name"-pair annotaions provide a consistent way.



Illustration:
This is not intended to explain problems, but I want to illustrate where 
this idea came.
A blip is a place where users communicate with each other. Then, what about 
robots? It is unnatural for robots to use a natural language to communicate 
with each other. So it is natural for them to use annotations. So, an 
annotation is a place where robots communicate with each other.
Some of the conversation of users can be understood by robots. For example, 
when Linky finds "http://www.xxx.com", then Linky understands that it is a 
url, but Linky does not understand other parts of the conversation. On the 
other hand, robots talk with each other in an annotation, and some of their 
conversation can be understood by users, by using javascript to display it 
in the blip.
Just like a robot can intervine with the conversation of users directly, 
users too have to have an ability to intervine with the converstion of 
robots directly in an annotation. So it is very important that the client 
application has a button to show the data of an annotation and give users 
the opportunity of editting it.
This is a way of collaboration of users and robots, I imagine.

The attached patch changes a few XML attributes in the examples to use
single quotes instead of double quotes, in conformance with the other examples.

In two cases, a different kind of quote is used at two ends of an attribute:

  verification-tag="f919211828218213812381238123'

1. In wavespec.xml and the document at
http://www.waveprotocol.org/draft-protocol-spec#element-attributes-wavelet-domai
n
, the word "wave" in section "wavelet-domain" should be "wavelet", isn't it?

2. In the operational transform document at
http://www.waveprotocol.org/draft-protocol-spec#element-attributes-wavelet-domai
n
, there's the following line:
[Wave document operations sport the following mutation components]
I'm guessing you mean sport->support

Error file attached.

From reading the protocol spec, it appears that UCE (Or Unsolicited
Commercial Waves (UCW)?) could still be a problem. I have read in the spec
that the underlying XMPP connections will be secured using TLS, but perhaps
we should go one step further and require validation of domain certificates
in order to prevent anonymous and ubiquitous junk-mail which has plagued
e-mail systems for years. One possible answer might be to use a resource
record in DNS to store the public key for a wave-domain and require the
validation of the certificate in order for wavelets to propagate between
wave-domains. An additional measure might be a methodology for allowing
wave-domains to validate users when wavelets are propagating. So,
wave-domains would be ensured that the source of the wavelet is from the
indicated server and that the user account is a valid user in good standing
prior to allowing that user to participate in a wave. This would make
current UCE/UCW all but impossible because every user would have to be
validated and could be individually denied. Bot nets would have no chance
because they cannot be validated. Mass accounts created on public servers
would be quickly sniffed out and locked upon suspicion of spamming. It
would solve many of the problems of modern messaging.

Within Content Mutations, please consider changing the representation of 
annotations to use standard XML, rather than a separate data stream.

It presents an unnecessary complexity to any wave storage system to store 
two separate data streams; both the document XML and the annotations 
stream. It also adds complexity to the protocol, the operational transform 
engine and other areas of the system.

The annotations should be stored within the XML document for the wave (eg. 
<annotationstart key="X" value="Y"></annotationstart>). There would then be 
no special requirements for the transmission, storage or transformation of 
annotations.

What steps will reproduce the problem?
1. /add [email protected]
2. /add [email protected]
3. type some text

--> Only [email protected] sees the digest of the modified wavelets in his client

What is the expected output? What do you see instead?

both foo and bar see the digest

Please use labels and text to provide additional information.

tobiast already has an outstanding patch that will fix this issue.

I followed the "guide" at http://code.google.com/p/wave-
protocol/wiki/Installation ( The post that is comment by Ilir.Halili, Jul 
31, 2009)




Imperox:/wave-protocol# ant -f build-proto.xml
Buildfile: build-proto.xml

compile:

BUILD FAILED
/wave-protocol/build-proto.xml:8: Execute failed: java.io.IOException: 
Cannot run program "protoc": java.io.IOException: error=2, No such file or 
directory

Total time: 3 seconds
Imperox:/wave-protocol# 

The attached patch fixes these small issues:

Typo/grammar fixes:
* existant → existent
* IE → i.e.,
* an Google → a Google
* effect → affect (when used as a verb)
* heirarchical → hierarchical
* attribiute → attribute
* whitepater → whitepaper
* an 'waveop' element → a 'waveop' element
* docuemnt → document
* ", however " → ". However, "
* within wave → within a wave
* Fixed various <foo< to <foo>

Other changes:
* Request Message → Request Element (to fit with Delta Element.. maybe the
* other way is preferred...)
* Linked "add participant operation" to the section on the addparticipant
element later in the document.
* Linked "Access control whitepaper" to the whitepaper.
* Changed "range of ops" to "range of operations"
* Changed the "urn:googlep:wave:requests" namespace in the example to
"urn:google:wave:requests". That is in line with the other examples. The
'p' is probably a typo
* Added periods at the end of several lines.
* Changed "MUST contain ONE" to "MUST contain exactly ONE" -- if that's the
intention, it seems more clear.
* Fixed copy-pasted wording of <removeparticipant> element.

What steps will reproduce the problem?
1. /add [email protected]
2. /add [email protected]
Result: Exception because the waveserver accepts both of the two add
participant ops and sends two waveletUpdate() events to the ClientFrontend,
which has a check that will catch this and throw an exception

What is the expected output? What do you see instead?

The waveserver / OT code should reject the second AddParticipant operation
if the participant is already on the specified wavelet

We currently use enums for HashAltgorithm and SignatureAlgorithm in the 
protobufs. Should we ever add a new value to the enum, and send a signature 
to a server that runs old code, the hash_algorithm field will be treated as 
not being there. But since it's marked required, badness will ensue. 

We probably either want to switch away from enums, or make the algorithm 
fields options, or something like that.

We had decided not to repurpose xmpp's from/to because they are used for 
message routing.
This means we need user-id as a common attribute on waveops to know who is 
making the change.

What steps will reproduce the problem?
1. pull source as per installation instructions
2. ant
3. ./run-server.sh

What is the expected output? What do you see instead?

The expected output is a message indicating the server has started up. What
I get instead is:

./run-server.sh 
Exception in thread "main" java.lang.NoClassDefFoundError:
org/xmpp/component/ComponentException
Caused by: java.lang.ClassNotFoundException:
org.xmpp.component.ComponentException
    at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
Could not find the main class:
org.waveprotocol.wave.examples.fedone.ServerMain.  Program will exit.


What version of the product are you using? On what operating system?

as per hg pull

Please provide any additional information below.

I'm using Ubuntu Jaunty, Java SDK6

The schema states that both <delta> and <applieddelta> can be <iq> children.
The example in 6.3.3 of the spec shows a <delta> as a child of <iq>.

However, the spec fails to mention that the <delta> element can be a child
of <iq>.
It also mentions <applieddelta> under a section called "Delta element",
which may confuse the reader.

There is what looks like a copy-and-paste type of mistake in the current
version of the draft specification
(http://www.waveprotocol.org/draft-protocol-spec#mutation-children):

"The <delete-element-start/> indicates the deletion of the start-tag
directly under the cursor. i.e., the position directly after the cursor. It
MUST be paired with a later <delete-anti-element-end/>."

should most likely be

"The <delete-element-start/> indicates the deletion of the start-tag
directly under the cursor. i.e., the position directly after the cursor. It
MUST be paired with a later <delete-element-end/>."

to be symmetric to the descriptions of <delete-element-end> and
<delete-anti-element-end>.

Dennis

I propose to have a consolidation-threshold (xsd:integer) attribute on 
wavelet so "older" Delta operations (MutateDocument) must be consolidated 
on server side once this threshold have been reach, so only deltas in 
range "last Delta operation *less* consolidation-threshold" are accesible 
for "activity history" on wavelet, olders would be see as a "unique Delta-
>operation->MutateDocument->characters"

Also I propose to apply Threshold not on real-time OT but to be applied 
applied only when wavelet fall to serialization state on sever, (no active 
sessions on wavelet for C2S and/or no OT concurring at that point on 
wavelet on federation scenario)

All severs known consolidation-threshold value so them can apply when 
appropiate wihtout further payload.

> What steps will reproduce the problem?
Connect to a wave server running more than one XMPP service.
If the wave server is not the first JID listed, you will be unable to 
connect, because the code in XmppDisco.java is testing them one at a time, 
and waiting forever for responses which do not come.

> What is the expected output? What do you see instead?
There should be disco#info requests and responses for more than just the 
first item.

> What version of the product are you using? On what operating system?
0bf003ae4aae, on Ubuntu Linux

> Please provide any additional information below.
My patch, which I just submitted via the request_codereview tool, fixes this 
issue by causing a disco#info request to be sent for each JID provided by 
the XMPP server in the disco#items response.

I also have added several small tweaks to the shell scripts for 
compatibility with dash, the 'sh' in Ubuntu, and for my own preferences.  
What is most significant, however, are my changes to XmppDisco.java.  You 
may also want to add more testing beyond the changes I have made to 
XmppDiscoTest.java.

I hope this will make new testing easier for people!

-- Kevin Cantu

It is difficult to have an access control in annotations.
Then, it is better to have a "aimedTo" attribute in annotations, where you 
can include the addresses of participants to whom the annotation is aimed.
If "aimedTo" attribute is an empty string, then this annotation is aimed to 
all participants.

This is not access control so all participants can theoretically see the 
annotation, so there is no difficulty in implementing it.


There are at least two benefits.

1. Those who are not listed in the "aimedTo" attribute may not be bothered 
by unrelated annotations.
2. This can make it possible to make a faster client javascript program.


Let's take an example of hyper-link. Consider this hyper-link links to 
another wavelet.
If the wavelet is a private reply whose participants are aaa@xxxx and 
bbb@yyy, then aimedTo="aaa@xxxx,bbb@yyy".

The client javascript program may ignore the annotation if you are not 
included in the aimedTo attribute.
In this way, you can avoid messy unrelated annotation display.
And the client javascript can run faster, because it does not need to check 
whether you have a right to access to that wavelet.

During disco querying, if the remote server has multiple components and one
or more is inaccessible (returns 404 because it has no DNS entry), the
error response is ignored instead of continuing to the next component.

E.g. remote components: [conference, proxy, pubsub, wave] and only "wave"
has a DNS entry. The processing will stop with "conference" when it returns
404. If this is fixed it then stops at "proxy" instead. Handling
IQ.Type.error as if it were IQ.Type.result works around the problem
(although it is then trying to examine the error response as though it were
a valid result).

Section 3.3.4.1 of the draft protocol spec:

'end-version-hash' -- REQUIRED attribute with the hash for the associated 
end version.

Should be:

'end-version-hash' -- OPTIONAL attribute with the hash for the associated 
end version.

Draft protocol spec, appendix A: 

          element wavesrv:wavelet-update {
            attribute wavelet-name { xsd:string },
            element wavesrv:applied-delta { text }*,
            commit-notice?
          }

Should be:

          element wavesrv:wavelet-update {
            attribute wavelet-name { xsd:string },
            element wavesrv:applied-delta { text }*,
            commit-notice?
          } *

What steps will reproduce the problem?
1. Ant
2. run-server.sh
3. java -jar dist/fedone-server-0.2.jar

What is the expected output? What do you see instead?
Some sign that it has started, got this instead:

Exception in thread "main" java.lang.UnsupportedClassVersionError: Bad 
version number in .class file
    at java.lang.ClassLoader.defineClass1(Native Method)
    at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
    at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
    at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
    at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
    at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:316)
    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:280)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
    at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:374)


What version of the product are you using? On what operating system?
Mac OS X, FedOne 0.2

Please provide any additional information below.
I saw that a person had sent in an issue with the same error output as 
mine while trying to run the run-server.sh file, and got a tip as to rather 
use "java -jar dist/fedone-0.2.tar", while the newest build doesnt have 
"fedone-0.2.jar" but rather "fedone-server-0.2.jar" I assume it is this one I 
am supposed to use.

Java is up-to-date with the newest version, and since I was able to compile 
with ant I assumed there wouldnt be a problem like this.

What steps will reproduce the problem?
1. Insert a link in a blip (ctl-L, cut/paste 'www.techcrunch.com').
2. Click it

What is the expected output? 
http://www.techcrunch.com

What do you see instead?
http://www.google.com/url?sa=D&q=www.techcrunch.com

Which doesn't work.  I have to explicitly include http:// to get

http://www.google.com/url?sa=D&q=http://www.techcrunch.com

Which does redirect.

However, I don't think it should redir at all. It seems unnecessary and
inefficient. 

CM

The attached patch fixes the mismatch in the pair name.  I didn't know what the 
preferred choice of 
a patch was, so I attached both an hg bundle and a unified diff.

What steps will reproduce the problem?
1. /add [email protected]
2. /remove [email protected]
-> exception

What is the expected output? What do you see instead?

no exception, user removed again


Please use labels and text to provide additional information.

tobias.thierer already has a patch for this. Will submit in the next days :)

What steps will reproduce the problem?
1. Join a wave, have a conversation
2. Restart your Wave Server
3. Have other participant continue to send information to existing wave

What is the expected output? What do you see instead?

What I believe should be happening is that the client should be seeing the
incoming delta, recognise that it doesn't have an entry in the index.wave
and then request the full history.

What instead is happening is that it seems to be baulking at the delta
because there isn't an entry in the index.wave. This means that the client
is unable to rejoin the existing wave.


What version of the product are you using? On what operating system?

latest hg pull on linux(Fedora)

Looks like the jar files are in a different place than what is specified in the 
run-client script. The 
right one that works is -

export CLASSPATH="build/core:third_party/runtime/jline/jline-
0.9.94.jar:third_party/runtime/google_collect/google-collect-1.0-
rc2.jar:third_party/runtime/protobuf/protobuf-java-2.1.0.jar"

What steps will reproduce the problem?
1. start the server
2. add two client(user)s (e.g. foo and bar) (using the dummy client)
3. let foo create a wave
4. let foo open the created wave
5. let foo add bar(@barshostname) to the wave
6. let bar open the wave
7. let both clients enter data into the wave
8. let foo remove bar(@barshostname) from the wave

Excerpt from the server debug output:

Jul 25, 2009 1:20:51 PM
org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl isLocalWavelet
INFO: ### WS is local?
[WaveId:schwarzbrot!w+If6cj0ziWzMU]/[WaveletId:schwarzbrot!conv+root] = true
Jul 25, 2009 1:20:51 PM
org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl submitDelta
INFO: ## WS: Submit result:
[WaveId:schwarzbrot!w+If6cj0ziWzMU]/[WaveletId:schwarzbrot!conv+root]
appliedDelta: signedOriginalDelta {
  delta {
    hashedVersion {
      version: 4
      historyHash: "\330>\021:m-\236c\233<\314\032\241\332\242\276\206zN\235"
    }
    author: "foo@schwarzbrot"
    operation {
      removeParticipant: "bar@schwarzbrot"
    }
  }
  signature {
    signatureBytes:
"\247H8\350\270\306\023\2455\240\212\252N\366c\345\002\203\334\243\300\233\216\0
27\327\333\'\343\276\257\212\324\271Q\377\302h\241
\235\231\212\240;\264\037\253N\305\304\243\rX\267\264\266\025U\310|b\200IS\326\0
26\210\362\342\316@Q-I\017\331\302\b*\031\002\030\275\223\020`\304\244\257w\372\
000\366\"t\032\346)\f\210x<#l\231\311\265\261!\202h\016\210`e)\362\242\272\254\3
54=\334\032\b\332w\224"
    signerId:
"\375\221\342%\031\247q\364Q\355\330\016\362\016\313\254\251\242M)\'\261\220 
\251\372>\\^?\365\272\240"
    signatureAlgorithm: SHA1_RSA
  }
}
hashedVersionAppliedAt {
  version: 4
  historyHash: "\330>\021:m-\236c\233<\314\032\241\332\242\276\206zN\235"
}
operationsApplied: 1
applicationTimestamp: 1248520851102

java.lang.IndexOutOfBoundsException: index (1) must be less than size (1)
        at
com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:273)
        at
com.google.common.base.Preconditions.checkElementIndex(Preconditions.java:248)
        at
com.google.common.collect.SingletonImmutableList.get(SingletonImmutableList.java
:53)
        at
org.waveprotocol.wave.examples.fedone.waveserver.DeltaSequence.subSequence(Delta
Sequence.java:85)
        at
org.waveprotocol.wave.examples.fedone.waveserver.ClientFrontendImpl.waveletUpdat
e(ClientFrontendImpl.java:369)
        at
org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl.submitDelta(Wave
ServerImpl.java:496)
        at
org.waveprotocol.wave.examples.fedone.waveserver.WaveServerImpl.submitRequest(Wa
veServerImpl.java:312)
        at
org.waveprotocol.wave.examples.fedone.waveserver.ClientFrontendImpl.submitReques
t(ClientFrontendImpl.java:246)
        at
org.waveprotocol.wave.examples.fedone.waveserver.WaveClientRpcImpl.submit(WaveCl
ientRpcImpl.java:132)
        at
org.waveprotocol.wave.examples.fedone.waveserver.WaveClientRpc$ProtocolWaveClien
tRpc$1.submit(WaveClientRpc.java:1616)
        at
org.waveprotocol.wave.examples.fedone.waveserver.WaveClientRpc$ProtocolWaveClien
tRpc.callMethod(WaveClientRpc.java:1727)
        at
org.waveprotocol.wave.examples.fedone.rpc.ServerRpcController.run(ServerRpcContr
oller.java:199)
        at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:636)

Full logfile on request

Using mercurial version up to (and including) changeset 29:275c6aa869bb

What steps will reproduce the problem?
1. Install the Wave Server and OpenFire
2. Create some seemingly necessary symbolic links, and file moves
3. Run ./run-client.sh, connect to a Wave Server, and observe that the
Client bails out when trying to create a new Wave

What is the expected output? What do you see instead?
When creating the new Wave, the following output is produced:
> /new                                                                    


22-Jul-2009 12:11:00
org.waveprotocol.wave.examples.fedone.rpc.ClientRpcChannel callMethod     

INFO: Calling a new RPC (seq 2), method
waveserver.ProtocolWaveClientRpc.Submit for
java.nio.channels.SocketChannel[connected local=/94.196.35.204:36320
remote=open.house404.co.uk/94.196.35.204:5222]                            


22-Jul-2009 12:11:00
org.waveprotocol.wave.examples.fedone.rpc.SequencedProtoChannel sendMessage

INFO: Sending message (waveserver.ProtocolSubmitRequest, seq 2) to:
java.nio.channels.SocketChannel[connected local=/94.196.35.204:36320
remote=open.house404.co.uk/94.196.35.204:5222]                            


Exception in thread "main" java.lang.IllegalStateException:
java.io.IOException: Broken pipe                                          

        at
org.waveprotocol.wave.examples.fedone.rpc.SequencedProtoChannel.sendMessage(Sequ
encedProtoChannel.java:222)

        at
org.waveprotocol.wave.examples.fedone.rpc.SequencedProtoChannel.sendMessage(Sequ
encedProtoChannel.java:238)

        at
org.waveprotocol.wave.examples.fedone.rpc.ClientRpcChannel.callMethod(ClientRpcC
hannel.java:145)

        at
org.waveprotocol.wave.examples.fedone.waveserver.WaveClientRpc$ProtocolWaveClien
tRpc$Stub.submit(WaveClientRpc.java:1807)

        at
org.waveprotocol.wave.examples.fedone.waveclient.common.ClientBackend.sendWavele
tDelta(ClientBackend.java:305)

        at
org.waveprotocol.wave.examples.fedone.waveclient.common.ClientBackend.sendWavele
tOperation(ClientBackend.java:281)

        at
org.waveprotocol.wave.examples.fedone.waveclient.common.ClientBackend.createNewW
ave(ClientBackend.java:249)

        at
org.waveprotocol.wave.examples.fedone.waveclient.common.ClientBackend.createNewW
ave(ClientBackend.java:234)

        at
org.waveprotocol.wave.examples.fedone.waveclient.console.ConsoleClient.newWave(C
onsoleClient.java:353)

        at
org.waveprotocol.wave.examples.fedone.waveclient.console.ConsoleClient.doCommand
(ConsoleClient.java:205)

        at
org.waveprotocol.wave.examples.fedone.waveclient.console.ConsoleClient.run(Conso
leClient.java:128)

        at
org.waveprotocol.wave.examples.fedone.waveclient.console.ConsoleClient.main(Cons
oleClient.java:488)

Caused by: java.io.IOException: Broken pipe                               


        at sun.nio.ch.FileDispatcher.write0(Native Method)                


        at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)    


        at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:122)       


        at sun.nio.ch.IOUtil.write(IOUtil.java:93)                        


        at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:352) 


        at
org.waveprotocol.wave.examples.fedone.rpc.SequencedProtoChannel$2.write(Sequence
dProtoChannel.java:164)

        at java.io.OutputStream.write(OutputStream.java:116)              


        at
com.google.protobuf.CodedOutputStream.refreshBuffer(CodedOutputStream.java:861)

        at
com.google.protobuf.CodedOutputStream.flush(CodedOutputStream.java:871)   


        at
org.waveprotocol.wave.examples.fedone.rpc.SequencedProtoChannel.sendMessage(Sequ
encedProtoChannel.java:220)

        ... 11 more                                                     

As I have never successfully created a new Wave, I am unsure as to what I
should expect, although I believe that the above output should never be
produced under normal circumstances. 

What version of the product are you using? On what operating system?
Top of tree, Fedora 10.

Please provide any additional information below.

Output of java -version:
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.5) (fedora-18.b16.fc10-i386)
OpenJDK Client VM (build 14.0-b15, mixed mode)

Using OpenFire version 3.6.4.

What steps will reproduce the problem?

1. run-server.sh
2. connect to xmpp server using Adium (OS X)
3. right click on xmpp account, choose discovery browser (in Adium)
4. left click on "Google Prototype" (in Adium)
5. server responds with a disco#info instead of a disco#items

What is the expected output? What do you see instead?

INFO: received XMPP packet:

<iq type="get" to="wave.vostro.n" id="AMPurpleJabberNode11,"
from="[email protected]/tlantic">
  <query xmlns="http://jabber.org/protocol/disco#items"/>
</iq>
Aug 16, 2009 7:05:33 PM
org.waveprotocol.wave.examples.fedone.federation.xmpp.WaveXmppComponent
sendPacket
INFO: sent XMPP packet: 
<iq type="result" id="AMPurpleJabberNode11," from="wave.vostro.n"
to="[email protected]/tlantic">
  <query xmlns="http://jabber.org/protocol/disco#info"/>
</iq>

What version of the product are you using? On what operating system?

mercurial sources
changeset:   62:827b02b4fa82
date:        Tue Aug 11 13:14:15 2009 +1000
summary:     Update console client help message for undo

Please provide any additional information below.

XmppDisco.java:102

should be NAMESPACE_DISCO_ITEMS, not NAMESPACE_DISCO_INFO

  void processDiscoItemsGet(IQ iq) {
    IQ response = new IQ(IQ.Type.result);
    WaveXmppComponent.copyRequestPacketFields(iq, response);
    response.setChildElement("query", WaveXmppComponent.NAMESPACE_DISCO_INFO);
    component
        .sendPacket(response, false, /* no retry */ null /* no callback */);

  }

$ hg clone https://wave-protocol.googlecode.com/hg/ wave-protocol
...

wave-protocol$ ant dist
Buildfile: build.xml

init:

proto_compile:

compile:
    [javac] Compiling 169 source files to wave-protocol/build/core
    [javac] Compliance level '1.4' is incompatible with target level '1.5'.
A compliance level '1.5' or better is required

BUILD FAILED
wave-protocol/build.xml:68: Compile failed; see the compiler error output
for details.

Total time: 1 second

SSL certificates may be issued with subjectAltName or CN of *.example.com,
as in RFC2818. Ideally this should be supported too, even though this is
XMPP not HTTP.

Patch implementing basic support for this attached.

The OT code doesn't work correctly for characters outside the range 
U+0000...U+FFFF.
Also, the code doesn't ensure that its input and output strings are well-formed 
UTF-8/UTF-16.

"The <removeparticipant> element is used to add a participant to a wave."

Presumably, removeparticipant is actually used to remove a participant from
the wave.

"The receiving entity MUST verify the user id is allowed to be added to the
wave."

Similarly issue in the sentence above.

Debian Lenny.

[xmpp-t@bsrv:~/wave]% ant dist      
Buildfile: build.xml

init:

proto_compile:
    [javac] Compiling 3 source files to /home/xmpp-t/wave/build/core
    [javac] Compliance level '1.4' is incompatible with target level '1.5'. 
A compliance level '1.5' or better is required

BUILD FAILED
/home/xmpp-t/wave/build.xml:56: Compile failed; see the compiler error 
output for details.

Total time: 0 seconds

What steps will reproduce the problem?
1. Let user A join a wavelet and type "hello". The wavelet's digest for
user A will be "hello"
2. Let user B join the wavelet. B's digest is initially empty.
3. Let B type "world". B's digest becomes "world" (A's digest becomes
"helloworld").

What is the expected output? What do you see instead?

B's digest is initially "hello" and then becomes "helloworld", just like
A's digest.

Currently, document-ids do not include enough information to guarantee them 
to be unique.  This could (not likely, but could) result in collisions when 
document creating operations are submitted to the authoritative Federation 
Host from multiple sources.

Suggested solutions so far are:

1) Include the domain of the submitting host in the document-id.  This 
guarantees no collisions.

2) Require document-ids to be at least a certain length, to make collisions 
much less likely.